ipfw nat tablearg, tcpdump односторонний
Добавлено: 2009-02-16 11:35:01
Две дурные проблемы на FreeBSD 7 c kernel nat + ipfw
Первая. Есть несколько сетевых интерфейсов (карточек) с разными IPшниками. Пишутся команды типа
После последней команды фря подтверждает ее, однако оригинально:
00700 nat 0 ip from table(1) to any
Куда делось слово tablearg - неясно. Что наиболее грустно - фря потом и работает с этим правилом так, как она его приняла, т.е. не меняя все пакеты, поскольку nat 0 у меня нет. Что особенно интересно - ipfw add 900 fwd tablearg ip from table(2) to any, принимается фрей с подтверждением 00900 fwd tablearg ip from table(2) to any, и, что особенно удивительно, работает, как и ожидалось после чтения доки. Решение изобрел тупое - заменил одну строчку (последнюю в приведенном коде) на 2 - ipfw add 700 nat 73 ip from table(1, 73) to any и ipfw add 700 nat 225 ip from table(1,225) to any - работает. В реальной системе с моими 5 внешними выделенками и 4мя локальными интерфейсами количество правил возросло потрясающе. Буду рад любым идеям на этот счет.
Вторая проблема еще дурнее. После fwd пакет перестает видится tcpdump'ом. Т.е. на интерфейсе, за которым по маске сети только шлюз и который не "дефаултный" пакет даже чисто теоретически может попасть только с помощью fwd (если он не предназначен именно этому чужому шлюзу, конечно). Так у меня и происходит. Однако, если на таком интерфейсе запуститть tcpdump -i blabla1 - я вижу только входящие пакеты. Все иходящие не видно tcpdump'ом, если они не предназначены именно шлюзу "с той стороны" - например, ARP или ICMP пакеты на шлюз - эти видно. Причем если даже пакеты непосредственно для чужого шлюза принудительно "запихать" с помощью fwd на этот же самый чужой шлюз - они доходят до него (он отвечает на них), но tcpdump их перестает видеть. Собссно вопрос: "Если я жить не могу без tcpdump'a, а жить хочется - что делать ?".
Первая. Есть несколько сетевых интерфейсов (карточек) с разными IPшниками. Пишутся команды типа
Код: Выделить всё
ipfw nat 73 config ip bu.bu.bu.73 redirect_port...
ipfw nat 225 config ip ga.ga.ga.225 redirect_port...
ipfw table 1 add la.la.la.la 73
ipfw table 1 add nu.nu.nu.nu 225
ipfw add 700 nat tablearg ip from table(1) to any
00700 nat 0 ip from table(1) to any
Куда делось слово tablearg - неясно. Что наиболее грустно - фря потом и работает с этим правилом так, как она его приняла, т.е. не меняя все пакеты, поскольку nat 0 у меня нет. Что особенно интересно - ipfw add 900 fwd tablearg ip from table(2) to any, принимается фрей с подтверждением 00900 fwd tablearg ip from table(2) to any, и, что особенно удивительно, работает, как и ожидалось после чтения доки. Решение изобрел тупое - заменил одну строчку (последнюю в приведенном коде) на 2 - ipfw add 700 nat 73 ip from table(1, 73) to any и ipfw add 700 nat 225 ip from table(1,225) to any - работает. В реальной системе с моими 5 внешними выделенками и 4мя локальными интерфейсами количество правил возросло потрясающе. Буду рад любым идеям на этот счет.
Вторая проблема еще дурнее. После fwd пакет перестает видится tcpdump'ом. Т.е. на интерфейсе, за которым по маске сети только шлюз и который не "дефаултный" пакет даже чисто теоретически может попасть только с помощью fwd (если он не предназначен именно этому чужому шлюзу, конечно). Так у меня и происходит. Однако, если на таком интерфейсе запуститть tcpdump -i blabla1 - я вижу только входящие пакеты. Все иходящие не видно tcpdump'ом, если они не предназначены именно шлюзу "с той стороны" - например, ARP или ICMP пакеты на шлюз - эти видно. Причем если даже пакеты непосредственно для чужого шлюза принудительно "запихать" с помощью fwd на этот же самый чужой шлюз - они доходят до него (он отвечает на них), но tcpdump их перестает видеть. Собссно вопрос: "Если я жить не могу без tcpdump'a, а жить хочется - что делать ?".
