URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 84287
[ Назад ]

Исходное сообщение
"непонятная реакция ipfw"

Отправлено KENTus , 27-Фев-09 20:36 
Вообщем следующая ситуация.
Бьюсь уже давно. Постараюсь рассказать как можно подробнее.
Стоит интернет-роутер (FreeBSD 6.4), интерфейс em2 смотрит в инет. Раздается инет посредством mpd5 (интерфейсы ng* подсеть 10.10.0.0/21).
Правила фаерволла прописаны жестко, разграничивая каждый интерфейс:
09999 skipto 12000 ip from any to any via em2
09999 skipto 21000 ip from any to any via ng*
т.е. на каждый интерфейс выделено 1000 правил (для em2 12000-12999), причем среди них часть на входящий трафик и часть на исходящий:
12200 skipto 12600 ip from any to any out xmit em2
между 12200 и 12599 - проходит проверка входящего трафика.
два правила 12599 и 12999 перенаправление всего входящего и исходящего трафика трафика на последнее запретное правило 65535, т.е. никак данный траф пересекаться не должен.
Здесь будет уместно сказать что нат проводится средствами netgraph как и сбор трафа для учета.
Наглядный пример прохождения пакета от юзера:
1. через ng* идет к серву, проходит проверка пакета правилами 21200-21599, где проверяется разрешение на вход к серваку и пакет заворачивается в ноду netgraph правилом:
21411 netgraph 1 ip from 10.10.0.0/21 to any in recv ng* in, где проходит export netflow и проходит ng_nat
затем пакет возвращается в фаер и доходя до
21599 skipto 65000 ip from any to any in recv ng*

2. выходя с сервера через em2 пакет попадает под правила 12600-12999 и проходит проверку на выходе, а также направляется на роутер прова:
12852 fwd "шлюз прова" ip from "внешний ип" to not "сеть прова"

3. возвращаясь обратно пакет попадает под правила 12200-12599 где он попадает в netgraph
12410 netgraph 23 ip from any to "внешний ип" in recv em2 in
где производится обратное преобразование nat и export netgraph, далее пакет возвращается дальше на правила фаервола
12599 skipto 65000 ip from any to any in recv em2

4. перед отправкой через ng* к юзеру пакет снова должен пройти весь фаер, т.е. он попадает на правила 21600-21999, где проходит проверку "можно-нельзя".

Для отладки фаера (правил очень много, поэтому и не могу все показать) использую контрольные правила, которые должны показать неучтенный траф:
12598 deny log logamount 200 ip from any to any in recv em2
12998 deny log logamount 200 ip from any to any out xmit em2
21598 deny log logamount 200 ip from any to any in recv ng*
21998 deny log logamount 200 ip from any to any out xmit ng*
т.е. после всех преобразований если что-то я не учел, то пакет должен попасть в лог.

Сама проблема:
в логах как раз по этому поводу выдается мура:
... kernel: ipfw: 12998 Deny TCP 89.108.90.179:80 10.10.1.26:2295 out via em2

Каким образом такое может случиться - пакет ломится в инет на 10.10.1.26 с реальным ипом какого-то серва через внешний интерфейс.
Каким-то образом пакет не попал в неграф и проскочил правила?

Помогите разобраться пожалуйста.

PS: sysctl net.inet.ip.fw.one_pass=0
    65535 deny ip from any to any


Содержание

Сообщения в этом обсуждении
"непонятная реакция ipfw"
Отправлено PavelR , 28-Фев-09 00:03 
Вроде умный чел, вроде умно всё написал, но че ж невнимательно то так..

ну пришел с ng* интерфейса пакет. Кто ж сказал что он обязательно придет с адреса, который на том конце туннеля ?

>1. через ng* идет к серву, проходит проверка пакета правилами 21200-21599, где
>проверяется разрешение на вход к серваку и пакет заворачивается в ноду netgraph правилом:
>21411 netgraph 1 ip from 10.10.0.0/21 to any in recv ng* in, где проходит export netflow
>и проходит ng_nat

Файрволл его пропустил, на входе, на правилах 21200-21599, в том числе _не_ завернул на netgraph 1.

На выходе оно соотв попадает на 12998.


"непонятная реакция ipfw"
Отправлено KENTus , 28-Фев-09 10:46 
>Вроде умный чел, вроде умно всё написал, но че ж невнимательно то
>так..
>
>ну пришел с ng* интерфейса пакет. Кто ж сказал что он обязательно
>придет с адреса, который на том конце туннеля ?
>

Спасибо.
А с какого он еще адреса может прийти, если на той стороне ng* только 10.10.0.0/21?
Чего-то я не догоняю, а как там может оказаться пакет с реальным адресом?
Это подмена адреса в заголовке? на ng* пакет может прийти только с одной стороны, на сколько я понимаю...
Глядя на схему из мана по ipfw, мне не понять почему такое может быть.
И еще, в самом начале фаера есть такое правило:
00600 deny ip from not 10.10.0.0/21 to any in recv ng*


"непонятная реакция ipfw"
Отправлено PavelR , 28-Фев-09 13:18 
>
>Спасибо.
>А с какого он еще адреса может прийти, если на той стороне
>ng* только 10.10.0.0/21?
>Чего-то я не догоняю, а как там может оказаться пакет с реальным
>адресом?

Это проблемы удаленной стороны.

>Это подмена адреса в заголовке? на ng* пакет может прийти только с
>одной стороны, на сколько я понимаю...
>Глядя на схему из мана по ipfw, мне не понять почему такое
>может быть.
>И еще, в самом начале фаера есть такое правило:
>00600 deny ip from not 10.10.0.0/21 to any in recv ng*

Отлично. А оно работает (срабатывает) ?


// Разгадывать по описанию и складывать в голове таблицу правил - занятие малоприятное.
// Кроме того, там может быть что-то, что опущено в описании.
// Приводите полную таблицу правил. Пусть не сюда, а на другой ресурс типа paste.org.ru



"непонятная реакция ipfw"
Отправлено KENTus , 28-Фев-09 16:07 
>>И еще, в самом начале фаера есть такое правило:
>>00600 deny ip from not 10.10.0.0/21 to any in recv ng*
>
>Отлично. А оно работает (срабатывает) ?

Срабатывает и причем меня порадовал результат когда я его пару дней назад ввел, но это другая история.
Вот все правила: http://paste.org.ru/?80azd3
Вот ифейсы:
DMZ -   em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255
        ether ***
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
LAN -   em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 172.30.4.10 netmask 0xffffff00 broadcast 172.30.4.255
        inet 172.30.4.11 netmask 0xffffff00 broadcast 172.30.4.255
        ether ***
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
Inet    em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet 91.91.91.20 netmask 0xffffff00 broadcast 91.91.91.255
        inet 91.91.91.25 netmask 0xffffff00 broadcast 91.91.91.255
        ether ***
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
VPN -   tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 10.20.0.1 --> 10.20.0.2 netmask 0xffffffff
        Opened by PID 716
ng3: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1460
...
ng*: ...

Буду очень признателен если будет решена моя проблема.


"непонятная реакция ipfw"
Отправлено PavelR , 28-Фев-09 16:34 
что в таблице table(1) ?

"непонятная реакция ipfw"
Отправлено KENTus , 28-Фев-09 18:50 
>что в таблице table(1) ?

Пользователи,которым разрешен выход в инет, т.е. у кого оплачен инет.
Они из сети 10.10.0.0/21


"непонятная реакция ipfw"
Отправлено KENTus , 01-Мрт-09 15:09 
>>что в таблице table(1) ?
>
>Пользователи,которым разрешен выход в инет, т.е. у кого оплачен инет.
>Они из сети 10.10.0.0/21

спасибо за оказанное внимание
попробую проследить сам, есть идейка