Jump to content
Калькуляторы

NAT на пул белых адресов FreeBSD

есть n PPPoE брасов построенных на FreeBSD и mpd пользователи получают серые IP адреса и прямо на этих же брасах через нат получают интернет, есть возможность выделить пул белых адресов на каждый брас например сетку из 32 адресов, возникает вопрос каким из встроеных фаерволов и фильтров разумнее реализовать нат на пул адресов --- сейчас используется ipfw + natd которая может натить только на 1 адрес и фактом того что natd выполняется в user space создаёт лишнюю нагрузку. есть возможность вынести нат на отдельный сервер и поднять ospf между кластером брасов и этим сервером, хотелось бы узнать насколько такое оправдано? ведь тогда появляется единая точка отказа, либо поставить кваггу на каждый брас и подружить её с бордером на циске

Edited by mousus

Share this post


Link to post
Share on other sites

никто не мешает NAT зарезервировать. pf или ipfw на выбор. предпочтительно наверное второе, с точки зрения того что первое не параллелится.

Share this post


Link to post
Share on other sites

 

natd может натить на сколько угодно адресов, изучайте матчасть... на каждый адрес запускаете по natd на разных номерах портов.

 

никто не мешает NAT зарезервировать. pf или ipfw на выбор. предпочтительно наверное второе, с точки зрения того что первое не параллелится.

Первый не параллелится, а во втором утечки... :-) Нет в жизни счастья.

Share this post


Link to post
Share on other sites

и самое интересное что все чем-то все таки натят. неужели до сих пор таки течет? может кто-то путает просто это с очень быстрым наполнением таблицы трансляций, а таймауты большие?

Share this post


Link to post
Share on other sites

А почему бы тогда заинтересованному кругу лиц не скинуться и не оплатить доработку ipfw kernel nat, чтобы всем было счастье? Про pf не говорю, там у разработчиков твердые убеждения, что SMP "не нужен". Кроме того, в связи с появлением во FreeBSD 8.0 виртуализации сетевого стека, проблему масштабирования pf теоретически можно решить, запуская pf в нескольких jail, прибитых к отдельным процессорам/ядрам, и настроив CARP в режиме балансировки нагрузки. Сам так делать еще не пробовал, поэтому за работоспособность этой схемы не ручаюсь.

 

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

Edited by photon

Share this post


Link to post
Share on other sites

вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0 по типу :

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        inet xxx.xxx.xxx.1 netmask 0xffffff00
        inet xxx.xxx.xxx.2 netmask 0xffffff00
        inet xxx.xxx.xxx.3 netmask 0xffffff00

тогда возникает вопрос насколько это будет корректно ?

Share this post


Link to post
Share on other sites

 

маску только /32 поставьте, а не /24

 

собственно так в рекомендациях и написано делать...

 

 

PS: разницы по нагрузке с внешним интерфейсом нет...

Share this post


Link to post
Share on other sites
А почему бы тогда заинтересованному кругу лиц не скинуться и не оплатить доработку ipfw kernel nat, чтобы всем было счастье?

А что там дорабатывать? Вроде не течет он уже. А если и течет, то не так существенно.

По крайней мере, его уже не надо перезапускать раз в месяц.

Share this post


Link to post
Share on other sites
вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0 по типу :

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        inet xxx.xxx.xxx.1 netmask 0xffffff00
        inet xxx.xxx.xxx.2 netmask 0xffffff00
        inet xxx.xxx.xxx.3 netmask 0xffffff00

тогда возникает вопрос насколько это будет корректно ?

у меня тоже на lo0, но с маской /32, а также эти адреса проанонсированы во внутрь AS, торентщики довольны.

На какой интерфейс вешать не суть важно.

Share this post


Link to post
Share on other sites

есть кстати 2 варианта как с помощью pf раскидывать юзерей по пулу:

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 round-robin sticky-address

 

и

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 source-hash

 

в принципе работоспособны оба, но во втором тратится время на вычисление хэша, есть ли какая то статистика по загрузке системы чтобы сравнить эффективность обоих методов?

Share this post


Link to post
Share on other sites

Хеш вычисляется один раз при создании правила трансляции.

                break;
        case PF_POOL_SRCHASH:
                pf_hash(saddr, (struct pf_addr *)&hash, &rpool->key, af);
                PF_POOLMASK(naddr, raddr, rmask, (struct pf_addr *)&hash, af);
                break;
        case PF_POOL_ROUNDROBIN:
                if (rpool->cur->addr.type == PF_ADDR_TABLE) {
                        if (!pfr_pool_get(rpool->cur->addr.p.tbl,
                            &rpool->tblidx, &rpool->counter,
                            &raddr, &rmask, af))
                                goto get_addr;
                } else if (rpool->cur->addr.type == PF_ADDR_DYNIFTL) {
                        if (!pfr_pool_get(rpool->cur->addr.p.dyn->pfid_kt,
                            &rpool->tblidx, &rpool->counter,
                            &raddr, &rmask, af))
                                goto get_addr;
                } else if (pf_match_addr(0, raddr, rmask, &rpool->counter, af))
                        goto get_addr;

 

было бы интересно потестировать разные варианты.

Share this post


Link to post
Share on other sites
есть кстати 2 варианта как с помощью pf раскидывать юзерей по пулу:

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 round-robin sticky-address

 

и

 

nat on em0 inet from 172.16.0.0/16 to any -> x3.x4.x5.x6/27 source-hash

 

в принципе работоспособны оба, но во втором тратится время на вычисление хэша, есть ли какая то статистика по загрузке системы чтобы сравнить эффективность обоих методов?

Давно перешел с round-robin на source-hash с тем, чтоб проще было отчитываться кто куда с какого IP лазил, да и банило чтоб спамеров и прочих хулиганов на внешних ресурсах за дело и на одном адресе, а не кого попало и пока всю маску не испортят.

В момент перехода увеличения задержек и загрузки системы не заметил.

Начу маской /24.

Share this post


Link to post
Share on other sites

А я наоборот, с source-hash на round-robin sticky-address залез. %) С той же целью, причём. :)

Share this post


Link to post
Share on other sites

А я наоборот, с source-hash на round-robin sticky-address залез. %) С той же целью, причём. :)

с той же целью не получится - он же только на время стейта прилепляется.

Share this post


Link to post
Share on other sites

неа, round-robin sticky-address работает с темже ипешником даже после реконнекта PPPoE сессии под темже логином и паролем, и это присвоение держится всё время что запущен pf при перезапуске сервака в следующий раз получаются другие адреса, которые тоже живут до перезапуска, и естественно это справедливо только когда из биллинга прилетает абоненту статический ипешник. замечены кстати небольшие задержки при вэбсёрфинге связанные с однопоточностью pf с ipfw и natd странцы грузятся влёт по клику а тут происхдит задержка на полсекунды гдето

Share this post


Link to post
Share on other sites

неа, round-robin sticky-address работает с темже ипешником даже после реконнекта PPPoE сессии под темже логином и паролем, и это присвоение держится всё время что запущен pf при перезапуске сервака в следующий раз получаются другие адреса, которые тоже живут до перезапуска, и естественно это справедливо только когда из биллинга прилетает абоненту статический ипешник. замечены кстати небольшие задержки при вэбсёрфинге связанные с однопоточностью pf с ipfw и natd странцы грузятся влёт по клику а тут происхдит задержка на полсекунды гдето

Вы с source-hash без указания хэша не путаете?

Share this post


Link to post
Share on other sites

а там та же история, только с тем приколом что ипешники на которые pf натит по другому распределяются, проверено экспериментально

 

но вот задержки при открытии страниц на некоторых сайтах например видео.мэил.ру непонятны, на ipfw их нет

Edited by mousus

Share this post


Link to post
Share on other sites
а там та же история, только с тем приколом что ипешники на которые pf натит по другому распределяются, проверено экспериментально
man pf.conf
source-hash

The source-hash option uses a hash of the source address to deter-

mine the redirection address, ensuring that the redirection address

is always the same for a given source. An optional key can be

specified after this keyword either in hex or as a string; by de-

fault pfctl(8) randomly generates a key for source-hash every time

the ruleset is reloaded.

round-robin

The round-robin option loops through the redirection address(es).

.....

Additionally, the sticky-address option can be specified to help ensure

that multiple connections from the same source are mapped to the same

redirection address. This option can be used with the random and round-

robin pool options. Note that by default these associations are de-

stroyed as soon as there are no longer states which refer to them; in or-

der to make the mappings last beyond the lifetime of the states, increase

the global options with set timeout src.track. See STATEFUL TRACKING

OPTIONS for more ways to control the source tracking.

Share this post


Link to post
Share on other sites
маску только /32 поставьте, а не /24

 

собственно так в рекомендациях и написано делать...

 

 

PS: разницы по нагрузке с внешним интерфейсом нет...

Уважаемые гуру .. можно ссылку на рекомендации ?

 

п.с. У меня сделано заруливанием пула нат адресов на фейковую сетку между натом и бгп, ...

Все работает, но вариант с привинчиванием 512 адресов на интерфейс выглядит красиво (настройки только на нате, а в моем варианте нужно еще и на бгп делать), но както стремновато ...

Share this post


Link to post
Share on other sites

на бгп ничего лишнего привинчивать не надо кроме маршрута на более крупную сеть(/23) в сторону твоего ната.

Edited by XeonVs

Share this post


Link to post
Share on other sites

Да эт я знаю )))

Хотелось бы просто увидеть ИМЕННО "рекомендации", так как рытье инета кроме ссылок в наг по подобному вопросу ничего полезного не дает (((

 

Да и собсно почитать, чем вариант с фейкомой подсеткой хуже/лучше/пофих, чем с прописываением кучи адресов на ло0.

Как бы, вопрос то даже один - не будет ли плохо серваку от такого счастья в виде полкило адресов ?

Share this post


Link to post
Share on other sites
Да эт я знаю )))

Хотелось бы просто увидеть ИМЕННО "рекомендации", так как рытье инета кроме ссылок в наг по подобному вопросу ничего полезного не дает (((

 

Да и собсно почитать, чем вариант с фейкомой подсеткой хуже/лучше/пофих, чем с прописываением кучи адресов на ло0.

Как бы, вопрос то даже один - не будет ли плохо серваку от такого счастья в виде полкило адресов ?

хз, у меня 64 адреса только. на производительности особо не сказалось, если не считать нагрузку от торентщиков которые смогли в такой позе через нат у друг друга качать. Но с запуском внутренних ретрекеров, эта проблема не актуальна стала особо, популярный трафик замыкается внутри локалки.

Share this post


Link to post
Share on other sites
на производительности особо не сказалось, если не считать нагрузку от торентщиков которые смогли в такой позе через нат у друг друга качать.

Оо! Уже интереснЕе ..пожалуй попробую для теста таким макаром тоже сделать ..

Share this post


Link to post
Share on other sites

у меня пока на 2 брасах по 32 адреса сетки на ло0 прописаны, в сумме брасы пока 100 мегабит трафа молотят.

 

l0-bras2# pfctl -ss | wc -l

14540

 

l0-bras2# netstat -I em0 -w 1

input (em0) output

packets errs bytes packets errs bytes colls

3150 0 3154183 2484 0 704660 0

3138 0 3108128 2535 0 680815 0

3110 0 3128752 2417 0 682385 0

3344 0 3157524 2603 0 765774 0

3168 0 3127617 2526 0 755536 0

3544 0 3317742 2606 0 745831 0

 

это днём, вечером естественно в 2 -3 раза больше циферки, и усё ходит)) асечники счастливы

Share this post


Link to post
Share on other sites

 

Почему-то 16000 интерфейсов на сервере и миллион раутов никого не удивляют, а какие-то пол-тыщи алиасов пугают до дрожи.

Ну а религия не позволяет повесить на тестовой машине и посмотреть.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this