Конвертирование белих ip в серие

[Dr.zlo]

У меня вопрос по правилу pf. Помогите разабратся.
nat pass on em0 from 192.168.0.0/16 to any -> xx.xx.xx.xx/26
Если я правильно понимаю то ето правило должно раздавать белие ip клієнтам. Вопрос в том если у меня клиентов в нете бивает больше чем белих ip. Как поведьот себя ето правіло. По логіке может бить 3 варианта.
1. В inet вийдут тока те кому хватило ip.
2. В inet вийдут все но те кому не хватило ip получат последній ip.
3. В inet вийдут все но те кому не хватило ip начнут получать ip сначала таким образом што на некоторих ip будет по несколько людей.
І ещьо вопрос нужна лі мне пропісивать в аліаси все белие ip што у меня есть ілі хватит тока ifconfig inet xxx.xxx.xxx.xxx netmask 255.255.255.192.

[Aivanzipper]

а у Вас вообще работает такой нат?

[Dr.zlo]

сечас работает вот так nat pass on em0 from 192.168.0.0/16 to any -> em0.
Но так как нам провайдер видал с одной сети 32 ip а потом понепонятной мне досих пор причине отобрал і оставил там один ip і видал в другом діапазоне ip понятно што іх там больше. А ви как думаете будет оно вот так работать

[Aivanzipper]

мне кажется, что назначить сетевухе em0 ПОДСЕТЬ xx.xx.xx.xx/26 не получится ) рещается это другими механизмами, с которыми я еще не сталкивался на своей практике

[Dr.zlo]

Вообщето оно должно вот так реализововатся. Покрайней мере так пишет в доках.

[Aivanzipper]

Да, Вы правы, можно указывать Сетевой блок CIDR.

Вот, накопал:

пул адресов используется для трансляции адресов в правилах nat.
   Соединение, которое имеет адрес источника транслируется в адрес пула,
   при этом базируясь на определенном методе. Это может оказаться очень
   полезным в случае. когда PF транслирует адреса для очень большой сети.

   Так как число одновременных NAT соединений на один внешний адрес
   ограниченно, выделение для этих целей пула адресов позволит
   значительно увеличить число пользователей.

   В этом примере пул из двух адресов используется для трансляции
   исходящих пакетов. Для каждого исходящего соединения PF производит
   ротацию адресов методом round-robin:

   nat on $ext_if inet from any to any -> { 192.0.2.5, 192.0.2.10 }

   Единственным недостатком этого метода будет то, что не всегда будет
   соблюдатся соответствие между исходным адресом и адресом трансляции.

   Это может вызвать проблему при заходе на web - узлы, проверяющих
   валидность пользователя на основании IP адреса. Решением этой проблемы
   может стать использование метода source-hash для привязки внутреннего
   адреса к адресу трансляции. В этом случае адресный пул должен быть
   определен как сетевой блок CIDR:

   nat on $ext_if inet from any to any -> 192.0.2.4/31 source-hash

   В этом правиле nat используется пул адресов 192.0.2.4/31 (192.0.2.4 -
   192.0.2.5) как адреса трансляции для исходящих пакетов. Каждый
   внутренний адрес будет всегда транслироваться в свой внешний адрес,
   так как указано ключевое слово source-hash.

[Dr.zlo]

Харашо тагда штоби сделать так штоб работало как в варианте 3 мойом. мне нада написать чьота такое
nat pass on em0 from 192.168.0.0/16 to any -> xxx.xxx.xxx.xxx/26 source-hash.
Поправте если я не прав ?

[Aivanzipper]

вроде правильно, тестируйте

[Dr.zlo]

В том то и дело што я не магу тестануть. На боевом серваке если я такое сделаю то меня за 5 секунд схавают. А разработчики билинга што об етом думают ?

[Elisium]

Вот вариант на моем серваке:

Код:

ext_if="em1"
nat pass on $ext_if from {192.168.0.0/16,10.0.0.0/8} to any -> х.х.х.х/уу source-hash

Вариант в верхнем посте правильный.

[goletsa]

Вы должны повесить на em0 все доступные вам адреса той подсети.
Вообще такую большую подсеть  вешать на один интерфейс сервера это бред.

К томуже белый адрес будет только у сервера, у клиентов будут серые.
Простой вариант часть адресов binat'ом выделить как внешние для клиентов а /16 подсеть поделить на несколько небольших (например /20) и выдавать на них под одному адресу.

У меня например сделано по другому. Есть некоторые адреса на сервере которые натятся как серые (по одной внешке на подсеть). А остальные форвардятся как белые на другой сервер.

[Elisium]

Вы должны повесить на em0 все доступные вам адреса той подсети.
Вообще такую большую подсеть  вешать на один интерфейс сервера это бред.

К томуже белый адрес будет только у сервера, у клиентов будут серые.
Простой вариант часть адресов binat'ом выделить как внешние для клиентов а /16 подсеть поделить на несколько небольших (например /20) и выдавать на них под одному адресу.
...

Чеж тут бредового У него всего то /26я подсеть. Все зависит от количества активных клиентов. Если их много, то чем больше натовский пул, тем лучше.
У меня, например, под нат выделена /23я сеть, потому что на всех работающих в данный момент клиентов нехватает реальников, и вторая /23 под бинат.

п.с. и на ем0 можно повесить только один адрес из той своей /26й подсети.
У нас тоже был такой вариант до перехода на свою автономку.

[goletsa]

Хм. Странно. Я всегда считал что для того чтобы прописать адрес для нат его надо физически повесить на интерфейс.

[Dr.zlo]

Читайте внимателней тему я хочю конвертить белие в серие а не видавать белие. То што ето правильное правило я знаю. Мне интересно будет ли так если у меня клиентов в нет вишло больше чем у меня раельних ипов:
1. В inet вийдут тока те кому хватило ip.
2. В inet вийдут все но те кому не хватило ip получат последній ip.
3. В inet вийдут все но те кому не хватило ip начнут получать ip сначала таким образом што на некоторих ip будет по несколько людей.

[versus]

Читайте внимателней тему я хочю конвертить белие в серие а не видавать белие. То што ето правильное правило я знаю. Мне интересно будет ли так если у меня клиентов в нет вишло больше чем у меня раельних ипов:
1. В inet вийдут тока те кому хватило ip.
2. В inet вийдут все но те кому не хватило ip получат последній ip.
3. В inet вийдут все но те кому не хватило ip начнут получать ip сначала таким образом што на некоторих ip будет по несколько людей.

Ты просто логику не правильно описал, что значит получить белый айпи из диапазона будучи за натом ?
Интернет трафик он дискретен, постоянна лишь сессия, и уже от алгоритма разработчика ната зависит как он будет держать сессию, в пределах одной сессии работы с конкретным сервером или в течении определенного периода жизни работы серого айпи с белым. Поэтому ответ на твой вопрос может дать только человек , который пересмотрел исходники и разобрался как в текущем релизе это реализовано. Лично мое мнение, что при исчерапании доступных свободных айпишников, другие участники будут получать рандомно белый айпи который он может разделять в одно и то же время с другим человеком, хотя возможно я не прав, спорить не буду