The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Мета-информация пакета при прохождении через ipfw nat"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Открытые системы на сервере (Маршрутизация, NAT / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 12:20 
Доброго дня!

Был бы очень признателен, если бы кто-то прояснил ситуацию с прохождением
пакетов через сетевой стёк - добавление мета-информации о 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=0

ipfw_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, то есть языком ipfw

in 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 какая мета-информация в пакета? Как она меняется?


Заранее всем спасибо!

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Pahanivo email(ok) on 08-Фев-10, 12:38 
уважаемый, вместо того чтобы лить воду лучшебы почитали маны:
man ipfw
man dummynet
местный поиск
гугл
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 12:56 
>уважаемый, вместо того чтобы лить воду лучшебы почитали маны:
>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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Алексей (??) on 08-Фев-10, 14:10 
Много воды и непонимание сути:

никакой метаинформации в пакетах нет,- все эти in_recv, src-ip 10.10.10.1 и т.д.,- это скорее условие, указывающее ipfw к каким пакетам данное правило применяется. Т.е, Вы создаёте набор правил для пакетов, наложив условие на каждый пакет. Правило будет применяться только к тем пакетам, которые удовлетворяют условию. Если пакет не удовлетворяет условию,- он попросту проходит в следующее правило. Если удовлетворяет,- применяется действие (allow, deny) и обработка пакета прекращается. Но, после natd пакет попадает в следующее правило.

Таким образом пакет проходит весь список правил до первого "сработавшего" и попадает на обработку на более высокий уровень, в приложение, работающее на этом компьютере.

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

Собственно, всё это написано в man ipfw

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 14:45 
Спасибо всем за помощь.
Ответ был получен из списка рассылки администраторов 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 и внешний интерфейс, а не на
внутренний. Более того, оно так даже и не заработает без ключа реверса -
нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от XoRe (ok) on 08-Фев-10, 15:08 
>[оверквотинг удален]
>какая мета-информация в пакета?
>    Как она меняется?
>
>
>Не меняется (нат инджектит в то же место, куда показывала метаинформация).
>В правиле ошибка - нат вешают на out и внешний интерфейс, а
>не на
>внутренний. Более того, оно так даже и не заработает без ключа реверса
>-
>нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.

В нате от ipfw не силен, не юзал.
Но, если исходить из логики, то да - надо вешать на исходящие, то есть добавить либо "xmit ext_if", либо "out via ext_if".

Нат (как и divert) инжектит в то же место, recv и xmit не сбрасываются.
Есть пара моментов:
- recv у пакета есть тогда, когда он откуда-то пришел (пакеты идущие от самого сервера не имеют recv).
- xmit у пакета появляется тогда, когда он проходит по правилам, уходя от сервера (проходящий через сервер пакет, проходит фаерволл 2 раза - на влете и на вылете).

Для понимания могу порекомендовать рисовать на бумаге "путешествие по правилом фаерволла пакета до ya.ru и обратно".

Для выяснения некоторых непонятных моментов рекомендую клепать кучу правил ipfw log до и после непонятного правила.
И потом анализировать /var/log/security.

Для оптимизации я бы порекомендовал правила вида "блочим левые пакеты" поставить в первом ряду.
После них nat и форвардинг.
А после них правила доступа к самому серверу.
С точки зрения "чтобы самые частые пакеты шли по наименьшему количеству правил".

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 15:27 
>Для оптимизации я бы порекомендовал правила вида "блочим левые пакеты" поставить в
>первом ряду.
>После них nat и форвардинг.
>А после них правила доступа к самому серверу.
>С точки зрения "чтобы самые частые пакеты шли по наименьшему количеству правил".

Оптимизация - следующая моя задача :) Будем думать.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Pahanivo email(ok) on 08-Фев-10, 15:11 
>[оверквотинг удален]
>какая мета-информация в пакета?
>    Как она меняется?
>
>
>Не меняется (нат инджектит в то же место, куда показывала метаинформация).
>В правиле ошибка - нат вешают на out и внешний интерфейс, а
>не на
>внутренний. Более того, оно так даже и не заработает без ключа реверса
>-
>нат увидит входящие пакеты и посчитает, что их надо разнатить обратно.

товарисч, читай те маны, внимательно читайте
потом смотрите стандартные примеры фри и хауту
ЗЫ по методанным - в самом пакете нет метаданных, НО(!) находясь "внутри" ipfw пакет однако может быть тегирован и тп, чтобы реализовывать более сложные схемы

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 15:24 
>ЗЫ по методанным - в самом пакете нет метаданных, НО(!) находясь "внутри"
>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}

этого замечания я нигде не увидел - не в одном мане, хауту!

Спасибо, что подсказал человек!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от rr on 08-Фев-10, 15:26 
>[оверквотинг удален]
>http://nuclight.livejournal.com/124348.html
>многое прояснила :)
>
>Но вот по-поводу - когда работаем с НАТ, то пакеты нужно направлять
>в НАТ только:
>
>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>2) входящие через внешний интерфейс - in recv ${ext_if}
>
>этого замечания я нигде не увидел - не в одном мане, хауту!

ничего подобного.

>
>
>Спасибо, что подсказал человек!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 15:31 
>[оверквотинг удален]
>>
>>Но вот по-поводу - когда работаем с НАТ, то пакеты нужно направлять
>>в НАТ только:
>>
>>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>>2) входящие через внешний интерфейс - in recv ${ext_if}
>>
>>этого замечания я нигде не увидел - не в одном мане, хауту!
>
>ничего подобного.

???

продолжите свою мысль, пожалуйста.
раз уж начали :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от rr on 08-Фев-10, 15:44 
1) исходящие через внешний интерфейс - out xmit ${ext_if}
2) входящие через внешний интерфейс - in recv ${ext_if}

не только

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Amator (ok) on 08-Фев-10, 15:51 
>1) исходящие через внешний интерфейс - out xmit ${ext_if}
>2) входящие через внешний интерфейс - in recv ${ext_if}
>
>не только

сильно :-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от XoRe (ok) on 08-Фев-10, 16:11 
>>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.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от Pahanivo email(ok) on 09-Фев-10, 16:44 

>Привыкайте, это опеннет, здесь любят такие категорические высказывания)
>
>Если в двух словах, то 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.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Мета-информация пакета при прохождении через ipfw nat"  +/
Сообщение от XoRe (ok) on 10-Фев-10, 10:37 
>эта тема работает с 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, как более гибкий вариант.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру