Доброго дня!Был бы очень признателен, если бы кто-то прояснил ситуацию с прохождением
пакетов через сетевой стёк - добавление мета-информации о recv, xmit интерфейсах
и со сменой направления in/out. Особенно после выхода из ipfw nat и pipe/queue.На каком-то примере думаю будет проще.
Может такой случай:
Шлюз с двумя сетевыми картами int_if и ext_if.
Задача шлюза - выпускать локальную сеть localnet в мир и разграничивать скорость -
каждому по потребностям.Будем использовать для этих целей:
FreeBSD 7.2
ipfw
ipfw nat
dummynet
net.inet.ip.fw.one_pass=0То есть, имеем:
## /etc/sysctl.conf
## net.inet.ip.fw.one_pass=0ipfw_cmd="/sbin/ipfw -q"
## Внешний интерфейс
ext_if="vr0"
## ip адрес сервера на внешнем интерфейсе
ext_ip="1.2.3.4"## Внутренний интерфейс
int_if="vr1"## Внутренняя сеть
localnet="10.10.10.0/24"## NAT
${ipfw_cmd} nat 1 config log if ${ext_if} reset same_ports deny_in## Входящий канал -> pipe 1
${ipfw_cmd} pipe 1 config bw 3950Kbit/s## Исходящий канал -> pipe 2
${ipfw_cmd} pipe 2 config bw 950Kbit/s## Очереди на входящий канал (pipe 1) -> 1x
# Важный трафик: TCP RST, TCP PSH, TCP SYN, TCP FIN
${ipfw_cmd} queue 10 config pipe 1 weight 100
# Сотрудники
${ipfw_cmd} queue 11 config pipe 1 weight 30 mask dst-ip 0xffffffff## Очереди на исходящий канал (pipe 2) -> 2x
# Важный трафик: TCP RST, TCP PSH, TCP SYN, TCP FIN
${ipfw_cmd} queue 20 config pipe 2 weight 100
# Сотрудники
${ipfw_cmd} queue 21 config pipe 2 weight 30 mask src-ip 0xffffffff
Шейпить трафик будем до входа в ipfw nat, и после выхода из него.Дальше, чтобы продолжить составление правил, нужно понимание процесса :)
Возьмём компьютер любого сотрудника. Сотрудник пытается зайти на сайт yandex.ru.
Пакет попадает в проход in через сетевую int_if, то есть языком ipfwin recv ${int_if}
Значит пишем следующее:
${ipfw_cmd} add 100 skipto 1000 ip from ${localnet} to any in recv ${int_if}
## in recv ${int_if}
${ipfw_cmd} add 1010 queue 20 ip from ${localnet} to any { tcpflags syn or tcpflags fin or tcpflags rst or tcpflags psh } in recv ${int_if}
${ipfw_cmd} add 1020 queue 21 ip from ${localnet} to any in recv ${int_if}Дальше после выхода из очереди пакет, если верить документации :), проверяется напротив следующего правила, а не
с самого начала ruleset-а и, я так понимаю, мета-информация пакета осталась прежней, то есть
in recv ${int_if}Поэтому пишем правило для NAT-а:
${ipfw_cmd} add 1030 nat 1 ip from ${localnet} to any in recv ${int_if}
NAT подменил ip сотрудника из localnet на ip интерфейса ext_if и, снова-таки если верить документации :), пакет идёт
в следующее правило, а не в начало ruleset-а, но мета-информация теперь какая???ip from ext_ip to any in recv ${int_if} теперь как-то неправильно,
так как у пакета теперь ip интерфейса ext_if :)ip from 1.2.3.4 to any in recv ${int_if}
???
Как оно на самом деле? После ipfw nat какая мета-информация в пакета? Как она меняется?
Заранее всем спасибо!
уважаемый, вместо того чтобы лить воду лучшебы почитали маны:
man ipfw
man dummynet
местный поиск
гугл
>уважаемый, вместо того чтобы лить воду лучшебы почитали маны:
>man ipfw
>man dummynet
>местный поиск
>гуглну это я сделал в первую очередь :)
просто с ipfw nat всё туманно - скудное описание.поэтому, если кто подскажет, куда идёт пакет после выхода из ipfw nat -
в начало ruleset-а, или на следующее правило, то буду очень благодарен!
и какая мета-информация остаётся-меняется-прикрепляется?то есть до ната, говоря языком ipfw
src-ip 10.10.10.1
dst-ip any
in recv ${internal_iface}потом правило для входа в нат
ipfw add 100 nat 1 from 10.10.10.10 to any in recv ${internal_iface}
после выхода какая мета-информация?
src-ip 1.2.3.4
dst-ip any???
net.inet.ip.fw.one_pass=0
Много воды и непонимание сути:никакой метаинформации в пакетах нет,- все эти in_recv, src-ip 10.10.10.1 и т.д.,- это скорее условие, указывающее ipfw к каким пакетам данное правило применяется. Т.е, Вы создаёте набор правил для пакетов, наложив условие на каждый пакет. Правило будет применяться только к тем пакетам, которые удовлетворяют условию. Если пакет не удовлетворяет условию,- он попросту проходит в следующее правило. Если удовлетворяет,- применяется действие (allow, deny) и обработка пакета прекращается. Но, после natd пакет попадает в следующее правило.
Таким образом пакет проходит весь список правил до первого "сработавшего" и попадает на обработку на более высокий уровень, в приложение, работающее на этом компьютере.
Приложением может быть как непосредственно запущенная пользовательская программа, работающая с сетью, так и демон маршрутизации, например, если он запущен. Во стором случае, пакет будет передан на другой интерфейс, где на выходе из ${external_interface} ещё раз пройдёт по всем правилам, условиям которых будет удовлетворять.
Собственно, всё это написано в man ipfw
Спасибо всем за помощь.
Ответ был получен из списка рассылки администраторов FreeBSD.Был бы очень признателен, если бы кто-то прояснил ситуацию с прохождением
пакетов через сетевой стёк - добавление мета-информации о recv, xmit
интерфейсах
и со сменой направления in/out. Особенно после выхода из ipfw nat и
pipe/queue.
http://nuclight.livejournal.com/124348.htmlПоэтому пишем правило для NAT-а:
${ipfw_cmd} add 1030 nat 1 ip from ${localnet} to any in recv ${int_if}
^^^ ^^^^^^^^^^^^^^^^^
Так нельзя.NAT подменил ip сотрудника из localnet на ip интерфейса ext_if и,
снова-таки если верить документации :), пакет идёт
в следующее правило, а не в начало ruleset-а, но мета-информация теперь
какая???ip from ext_ip to any in recv ${int_if} теперь как-то неправильно,
так как у пакета теперь ip интерфейса ext_if :)ip from 1.2.3.4 to any in recv ${int_if}
???
Как оно на самом деле? После ipfw nat какая мета-информация в пакета?
Как она меняется?
Не меняется (нат инджектит в то же место, куда показывала метаинформация).
В правиле ошибка - нат вешают на out и внешний интерфейс, а не на
внутренний. Более того, оно так даже и не заработает без ключа реверса -
нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.
>[оверквотинг удален]
>какая мета-информация в пакета?
> Как она меняется?
>
>
>Не меняется (нат инджектит в то же место, куда показывала метаинформация).
>В правиле ошибка - нат вешают на out и внешний интерфейс, а
>не на
>внутренний. Более того, оно так даже и не заработает без ключа реверса
>-
>нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.В нате от ipfw не силен, не юзал.
Но, если исходить из логики, то да - надо вешать на исходящие, то есть добавить либо "xmit ext_if", либо "out via ext_if".Нат (как и divert) инжектит в то же место, recv и xmit не сбрасываются.
Есть пара моментов:
- recv у пакета есть тогда, когда он откуда-то пришел (пакеты идущие от самого сервера не имеют recv).
- xmit у пакета появляется тогда, когда он проходит по правилам, уходя от сервера (проходящий через сервер пакет, проходит фаерволл 2 раза - на влете и на вылете).Для понимания могу порекомендовать рисовать на бумаге "путешествие по правилом фаерволла пакета до ya.ru и обратно".
Для выяснения некоторых непонятных моментов рекомендую клепать кучу правил ipfw log до и после непонятного правила.
И потом анализировать /var/log/security.Для оптимизации я бы порекомендовал правила вида "блочим левые пакеты" поставить в первом ряду.
После них nat и форвардинг.
А после них правила доступа к самому серверу.
С точки зрения "чтобы самые частые пакеты шли по наименьшему количеству правил".
>Для оптимизации я бы порекомендовал правила вида "блочим левые пакеты" поставить в
>первом ряду.
>После них nat и форвардинг.
>А после них правила доступа к самому серверу.
>С точки зрения "чтобы самые частые пакеты шли по наименьшему количеству правил".Оптимизация - следующая моя задача :) Будем думать.
>[оверквотинг удален]
>какая мета-информация в пакета?
> Как она меняется?
>
>
>Не меняется (нат инджектит в то же место, куда показывала метаинформация).
>В правиле ошибка - нат вешают на out и внешний интерфейс, а
>не на
>внутренний. Более того, оно так даже и не заработает без ключа реверса
>-
>нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.товарисч, читай те маны, внимательно читайте
потом смотрите стандартные примеры фри и хауту
ЗЫ по методанным - в самом пакете нет метаданных, НО(!) находясь "внутри" ipfw пакет однако может быть тегирован и тп, чтобы реализовывать более сложные схемы
>ЗЫ по методанным - в самом пакете нет метаданных, НО(!) находясь "внутри"
>ipfw пакет однако может быть тегирован и тп, чтобы реализовывать более
>сложные схемыhttp://nuclight.livejournal.com/124348.html
мета-данные (recv interface, xmit interface, направление in или же out)
"прикрепляются" к каждому пакету ядром (сетевой подсистемой ядра).ссылка
http://nuclight.livejournal.com/124348.html
многое прояснила :)Но вот по-поводу - когда работаем с НАТ, то пакеты нужно направлять в НАТ только:
1) исходящие через внешний интерфейс - out xmit ${ext_if}
2) входящие через внешний интерфейс - in recv ${ext_if}этого замечания я нигде не увидел - не в одном мане, хауту!
Спасибо, что подсказал человек!
>[оверквотинг удален]
>http://nuclight.livejournal.com/124348.html
>многое прояснила :)
>
>Но вот по-поводу - когда работаем с НАТ, то пакеты нужно направлять
>в НАТ только:
>
>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>2) входящие через внешний интерфейс - in recv ${ext_if}
>
>этого замечания я нигде не увидел - не в одном мане, хауту!ничего подобного.
>
>
>Спасибо, что подсказал человек!
>[оверквотинг удален]
>>
>>Но вот по-поводу - когда работаем с НАТ, то пакеты нужно направлять
>>в НАТ только:
>>
>>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>>2) входящие через внешний интерфейс - in recv ${ext_if}
>>
>>этого замечания я нигде не увидел - не в одном мане, хауту!
>
>ничего подобного.???
продолжите свою мысль, пожалуйста.
раз уж начали :)
1) исходящие через внешний интерфейс - out xmit ${ext_if}
2) входящие через внешний интерфейс - in recv ${ext_if}не только
>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>2) входящие через внешний интерфейс - in recv ${ext_if}
>
>не толькосильно :-)
>>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>>2) входящие через внешний интерфейс - in recv ${ext_if}
>>
>>не только
>
>сильно :-)Привыкайте, это опеннет, здесь любят такие категорические высказывания)
Если в двух словах, то nat в ipfw можно сделать несколькими способами.
Те, что я знаю:
- nat самим ipfw - тут, скорее всего, как раз и действуют указанные вами ограничения.
- nat с помощью divert в демон natd - тут все зависит от настройки natd (в связи с этим возможны очень хитрые схемы натирования).
- nat с помощью ng_nat - делается через директиву "divert" или "netgraph" и, так же, все зависит от настройки ng_nat.Демон natd богат на функционал, поэтому с ним можно играться разными способами.
Например, можно повесить его не на интерфейс, а на ip адрес.
В этом случае натить (и разнатить) можно в любом месте ipfw.
Я баловался именно с ним, поэтому не знаю, можно ли в ng_nat и ipf nat назначить нат на ip адрес.Кстати, по скорости выигрывают первый и третий, так как все происходит в ядре, не выходя в userspace (на современном компе чувствуется при натировании канала от 10-50-100Мбит/с).
Ещё есть ipf nat, но я не игрался с ipf.
>Привыкайте, это опеннет, здесь любят такие категорические высказывания)
>
>Если в двух словах, то nat в ipfw можно сделать несколькими способами.
>
>Те, что я знаю:
>- nat самим ipfw - тут, скорее всего, как раз и действуют
>указанные вами ограничения.эта тема работает с 7.0 release (вроде, точно не помню)
>- nat с помощью divert в демон natd - тут все зависит
>от настройки natd (в связи с этим возможны очень хитрые схемы
>натирования).народ жалуется на глюки и тормоза при большой трафике - лично я оооочень много где юзал данную схему еще с 4 release - на SOHO сегменте все нормально робит
>- nat с помощью ng_nat - делается через директиву "divert" или "netgraph"
>и, так же, все зависит от настройки ng_nat.
>
>Демон natd богат на функционал, поэтому с ним можно играться разными способами.да, но он таки дает оверхед ...
>[оверквотинг удален]
>Например, можно повесить его не на интерфейс, а на ip адрес.
>В этом случае натить (и разнатить) можно в любом месте ipfw.
>Я баловался именно с ним, поэтому не знаю, можно ли в ng_nat
>и ipf nat назначить нат на ip адрес.
>
>Кстати, по скорости выигрывают первый и третий, так как все происходит в
>ядре, не выходя в userspace (на современном компе чувствуется при натировании
>канала от 10-50-100Мбит/с).
>
>Ещё есть ipf nat, но я не игрался с ipf.
>эта тема работает с 7.0 release (вроде, точно не помню)Да, я знаю, штука относительно новая.
>народ жалуется на глюки и тормоза при большой трафике - лично я
>оооочень много где юзал данную схему еще с 4 release -
>на SOHO сегменте все нормально робитКстати, с natd глюков не встречал.
Использую со времен 4.5.
Все время запускаю его с опциями same_ports и use_sockets.
Хотя нет, были странности.
Но для них ещё нужно постараться создать условия, а потом ещё нужно постараться их заметить)По поводу потребления реурсов.
Единственное, что может тревожить - при большом количестве соединений и трафика процесс natd может кушать 30 метров оперативки.
Но это не смертельно уже при 256 Мб оперативки.А большой трафик... смотря что считать большим)
Могу сказать насчет такой конфигурации:
CPU: Intel(R) Pentium(R) D CPU 2.66GHz (2679.56-MHz 686-class CPU)
Cores per package: 2
real memory = 1056899072 (1007 MB)
+ 2 интеловские сетевушки (fxp)Натит канал 10Мбайт/с (100Mbit/s).
Загрузку проца я не смотрел, насколько я помню, при 10Мбайт/с она где-то 30%.
Но там много идет на прерывания (это ещё без включенного polling).
Мне кажется, на относительно современном компьютере задумываться об оверхедах на natd нужно при каналах на несколько сотен мегабит.
А там я бы посоветовал ng_nat, как более гибкий вариант.