Комментарии 35
Просто, доступно, ничего лишнего. Отличная статья. В избранное однозначно!
Интересная статья, познавательно, спасибо.
Вот именно таких материалов хабру и не хватает.
Добро пожаловать на Хабр :)
Добро пожаловать на Хабр :)
Спасибо! Буду стараться на благо сообщества.
вы еще плюсоминусы ipfw nat забыли записать:
— невозможность нормально без тонны алиасов натить из под пула
— невнятная статистика
+ наконец перестало течь
+ в отличии от иных умеет активное фтп изкоробки что позволяет не держать рядом фтп прокси
+ не страдает детскими болезнями типа приколов с одновременными pptp сквозь нат
ЗЫ сам его и использую
— невозможность нормально без тонны алиасов натить из под пула
— невнятная статистика
+ наконец перестало течь
+ в отличии от иных умеет активное фтп изкоробки что позволяет не держать рядом фтп прокси
+ не страдает детскими болезнями типа приколов с одновременными pptp сквозь нат
ЗЫ сам его и использую
Странная настройка ipfw nat, у меня ядерный нат так работал:
ipfw nat 1 config redirect_addr some_nat_ip some_local_ip \
redirect_addr some_nat_ip some_local_ip
ipfw table 30 add some_nat_ip
ipfw table 30 add some_nat_ip
ipfw table 40 add some_local_ip
ipfw table 40 add some_local_ip
ipfw add 1 nat 1 ip from any to table\(40\)
ipfw add 2 nat 1 ip from table\(30\) to any
ipfw add 3 allow ip from any to table\(30\)
ipfw add 3 allow ip from any to table\(40\)
ipfw add 3 allow ip from table\(30\) to any
ipfw add 3 allow ip from table\(40\) to any
И еще, при всем при этом не заработало, пока не отключил TSO на карте
ipfw nat 1 config redirect_addr some_nat_ip some_local_ip \
redirect_addr some_nat_ip some_local_ip
ipfw table 30 add some_nat_ip
ipfw table 30 add some_nat_ip
ipfw table 40 add some_local_ip
ipfw table 40 add some_local_ip
ipfw add 1 nat 1 ip from any to table\(40\)
ipfw add 2 nat 1 ip from table\(30\) to any
ipfw add 3 allow ip from any to table\(30\)
ipfw add 3 allow ip from any to table\(40\)
ipfw add 3 allow ip from table\(30\) to any
ipfw add 3 allow ip from table\(40\) to any
И еще, при всем при этом не заработало, пока не отключил TSO на карте
еще в pf мне кажется стоит упомянуть про rdr
А есть ещё нат который с ppp идёт. Я его везде где pppoe соединения использую, вроде вполне себе нормально работает. Единственный минус, если нужно правило какое-нибудь типа проброса порта добавить, нужно pppoe-сессию перезапускать.
Касательно первого абзаца раздела «Немного сравнения».
Разводить в системе зоопарк из фаерволов очень нежелательно, дабы не ломать лишний раз голову на тему «как пакет пойдёт если огурцы ложка банка майонеза».
Для большинства целей подойдёт схема «nat при помощи нетграфа (без заворота трафика через ipfw); фаерволом — pf».
Для тех, кому надо нарезать трафик на туеву хучу IP-адресов — организацию ната взять с предыдущей схемы, резалку трафика реализовать на думминете.
А два и более фаеров на одной машине — жёппа.
Разводить в системе зоопарк из фаерволов очень нежелательно, дабы не ломать лишний раз голову на тему «как пакет пойдёт если огурцы ложка банка майонеза».
Для большинства целей подойдёт схема «nat при помощи нетграфа (без заворота трафика через ipfw); фаерволом — pf».
Для тех, кому надо нарезать трафик на туеву хучу IP-адресов — организацию ната взять с предыдущей схемы, резалку трафика реализовать на думминете.
А два и более фаеров на одной машине — жёппа.
PF не дружит с SMP, соответственно PPS по сравнению с IPFW достаточно низок, сам проверял…
еще я пытался PF атаки отбивать, так вот при использовании динамических таблиц система отказывает во входе. ipfw позволяет зайти, т.к. SMP поддерживается и долгий поиск по таблице не замедляет всю сетевую активность.
В примере для ipfw во втором правиле not table\(10\) лучше заменить на any out или отвлечься и объяснить, зачем нужна эта таблица.
Потому что делать to any дурной тон в общем и целом. Кроме того далеко не все нужно натить — например me и соседние хосты. Давить нат излишними естепблишед сессиями если оные могут нативно раутиться.
Мало именно сравнения и совсем нет холивара — без этого читать неинтересно. :-) Что использует в работе сам автор?
natd сейчас практического смысла по сути не имеет — если стоит задача по быстрому дать интернет в офисе, то проще вообще не трогать ipfw, а сделать все сразу на pf — там две строчки написал и уже работает. Ну и в целом — гонять трафик из ядра в user-space — это не дело. Производительность, кстати, измерять в Мегабитах не вполне корректно — лучше, все-таки, в pps.
ipfilter — его вообще хоть кто-нибудь использует? Такой же привет из прошлого, как natd…
pf — как уже сказано выше — легок и прост в первом приближении. Но т.к. сделан не на libalias — не умеет проксировать активный FTP и еще кое-чего по мелочи — это создает излишний геморрой. Плюс на серьезных нагрузках сильно грузит проц — я его профилировал через hwpmc — там пробег по всем state'ам очень много времени занимает и это не лечится.
ng_nat — все-таки вещь не массовая, ИМХО. Хотя я его использовал из любопытства на паре серверов — работал и каши не просил. Но человеку без подготовки netgraph вообще лучше не трогать…
ipfw nat — на мой взгляд для серьезных нагрузок оптимальный вариант. Вся мощь libalias'а, никаких заморочек с настройками… Единственная проблема, с которой пришлось в свое время столкнуться — для того, чтобы создать больше сотни (примерно, точно не помню) редиректов пришлось немного патчить ядро — размер буфера там одного увеличить… Но, возможно, в последних версиях Фри это уже поправили — не проверял.
Резюмируя, я бы остановился на двух типичных сценариях использования и, соответственно, оптимальных файрволлах/натах:
pf — для использования не в телекоммуникациях, а просто с корпоративе, где нет феерических объемов трафика. ipfw не использовать вообще — делать все на pf. Синтаксис очень простой и понятный, мониторинг — удобный, производительность — достаточная для указанных целей
ipfw — для серьезного применения. Благо теперь в нем есть все-все-все и это нормально работает. Синтаксис, конечно, сложнее, но это издержки фич. Если pf можно сравнить с языком программирования высокого уровня, то ipfw — ассемблер. :-) Однако, в достаточно большом количестве случаев это все не особенно нужно и не требуется.
natd сейчас практического смысла по сути не имеет — если стоит задача по быстрому дать интернет в офисе, то проще вообще не трогать ipfw, а сделать все сразу на pf — там две строчки написал и уже работает. Ну и в целом — гонять трафик из ядра в user-space — это не дело. Производительность, кстати, измерять в Мегабитах не вполне корректно — лучше, все-таки, в pps.
ipfilter — его вообще хоть кто-нибудь использует? Такой же привет из прошлого, как natd…
pf — как уже сказано выше — легок и прост в первом приближении. Но т.к. сделан не на libalias — не умеет проксировать активный FTP и еще кое-чего по мелочи — это создает излишний геморрой. Плюс на серьезных нагрузках сильно грузит проц — я его профилировал через hwpmc — там пробег по всем state'ам очень много времени занимает и это не лечится.
ng_nat — все-таки вещь не массовая, ИМХО. Хотя я его использовал из любопытства на паре серверов — работал и каши не просил. Но человеку без подготовки netgraph вообще лучше не трогать…
ipfw nat — на мой взгляд для серьезных нагрузок оптимальный вариант. Вся мощь libalias'а, никаких заморочек с настройками… Единственная проблема, с которой пришлось в свое время столкнуться — для того, чтобы создать больше сотни (примерно, точно не помню) редиректов пришлось немного патчить ядро — размер буфера там одного увеличить… Но, возможно, в последних версиях Фри это уже поправили — не проверял.
Резюмируя, я бы остановился на двух типичных сценариях использования и, соответственно, оптимальных файрволлах/натах:
pf — для использования не в телекоммуникациях, а просто с корпоративе, где нет феерических объемов трафика. ipfw не использовать вообще — делать все на pf. Синтаксис очень простой и понятный, мониторинг — удобный, производительность — достаточная для указанных целей
ipfw — для серьезного применения. Благо теперь в нем есть все-все-все и это нормально работает. Синтаксис, конечно, сложнее, но это издержки фич. Если pf можно сравнить с языком программирования высокого уровня, то ipfw — ассемблер. :-) Однако, в достаточно большом количестве случаев это все не особенно нужно и не требуется.
Единственное, что в ipfw не хватает, команды для защиты от синфлуда и рейтлимита во временном периоде.
Согласен с Вашей точкой зрения. Сам использую в работе ipfw nat.
А ipfilter все еще встречается мне. Не так часто как остальные, но довольно, чтоб не оставить его без внимания. ng_nat тоже довольно часто встречается, у меня тоже с ним проблем не было никогда — настроил и забыл.
А ipfilter все еще встречается мне. Не так часто как остальные, но довольно, чтоб не оставить его без внимания. ng_nat тоже довольно часто встречается, у меня тоже с ним проблем не было никогда — настроил и забыл.
> ipfilter — его вообще хоть кто-нибудь использует?
приходится некоторым :) на Solaris другого нет :)
приходится некоторым :) на Solaris другого нет :)
Немножко использую pf, но знакомился с ним глубоко, но не пригодилось. Пока он у меня только маршрут следования пакетов меняет в зависимости от источника.
А у меня вот так правила написаны:
# Internet settings
oif=«em0»
onet=«84.237.22.0»
mask=«255.255.255.128»
oip=«84.237.22.3»
# Intranet settings
iif=«re0»
inet=«192.168.0.0»
imask=«255.255.255.0»
iip=«192.168.0.1»
# Rules for NAT
${ipfw} nat 1 config log if ${oif} same_ports
${ipfw} add 50 nat 1 all from ${inet}:${imask} to any out recv ${iif} xmit ${oif}
${ipfw} add 50 nat 1 all from any to ${oip} in recv ${oif}
При использовании модификаторов recv и xmit нет надобности использовать: «table\(10\) via em0, где table 10 – не идет через нат», к тому же как мне кажется это намного удобнее нежели использование модификатора via.
Естественно это справедливо только в ряде случаев.
# Internet settings
oif=«em0»
onet=«84.237.22.0»
mask=«255.255.255.128»
oip=«84.237.22.3»
# Intranet settings
iif=«re0»
inet=«192.168.0.0»
imask=«255.255.255.0»
iip=«192.168.0.1»
# Rules for NAT
${ipfw} nat 1 config log if ${oif} same_ports
${ipfw} add 50 nat 1 all from ${inet}:${imask} to any out recv ${iif} xmit ${oif}
${ipfw} add 50 nat 1 all from any to ${oip} in recv ${oif}
При использовании модификаторов recv и xmit нет надобности использовать: «table\(10\) via em0, где table 10 – не идет через нат», к тому же как мне кажется это намного удобнее нежели использование модификатора via.
Естественно это справедливо только в ряде случаев.
Такой вопрос, как увеличить таблицу трансляций для ng_nat?
Я так понимаю надо копаться с libalias, пока только нашел константы в исходниках libalias.
#define LINK_TABLE_OUT_SIZE 4001
#define LINK_TABLE_IN_SIZE 4001
Но неизвестно как отреагирует вся система ну увеличение этих констант.
Может есть какой-то более простой способ?
Второй вопрос, если запускаю 2,3 ноды ng_nat таблица трансляций у них общая, или у каждой ноды своя?
Я так понимаю надо копаться с libalias, пока только нашел константы в исходниках libalias.
#define LINK_TABLE_OUT_SIZE 4001
#define LINK_TABLE_IN_SIZE 4001
Но неизвестно как отреагирует вся система ну увеличение этих констант.
Может есть какой-то более простой способ?
Второй вопрос, если запускаю 2,3 ноды ng_nat таблица трансляций у них общая, или у каждой ноды своя?
+ не страдает детскими болезнями типа приколов с одновременными pptp сквозь нат
В PF это решается так
rdr on $ext_if proto {tcp,udp} from any to $exy_if port {1723} -> $vpnserver
rdr on $ext_if proto gre from any to $ext_if -> $vpnserver 
Классно, теперь бы еще шейпер с классами и список ip из mysql подцепить. :) И как раз то что нужно для нашей сетки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор и сравнение способов настройки NAT на FreeBSD