LINUX.ORG.RU
решено Форум — Admin  

iptables + SNAT


0

0

добрый день.

после:

iptables -F

iptables -t nat -F

iptables -t mangle -F

iptables -X

iptables -t nat -X

iptables -t mangle -X

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP

iptables -A FORWARD -p TCP -i eth1 --source 192.168.0.0/24 --destination 0.0.0.0/0 --match state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -p TCP -i eth0 --destination 192.168.0.0/24 --match state --state ESTABLISHED -j ACCEPT

iptables -t nat -A POSTROUTING -p TCP -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 10.1.1.1

наружу переодически падают icmp пакеты от 192.168.x.x, why?



Последнее исправление: kapasyatina (всего исправлений: 2)
← Целесообразно ли запускать KVM виртуализацию и виртуальную клатеризацию внутри сервера со следующими характеристиками?
Debian Lenny + Samba + LDAP: проблема добавления пользователя →

Ответ на: комментарий от anton_jugatsu

сорри, может путанно выразился..

на гейт внешнего интерфейса (10.1.1.2) приходят icmp пакеты с адресом источника из диапазона локальной сети (т. е. 192.168.0.0/24).

внешний гейт не мой, подробностей про него не знаю. выглядит это на нем так (кусок присланного мне лога): regular translation creation failed for icmp src inside: 10.1.1.2 dst outside: 192.168.0.38(type 3, code 13)

пакеты мои, как пролезают через 10.1.1.1 (мой шлюз) непонятно. очевидно ошибки в nat скрипте...

скрипт в первом сообщении. (без INPUT, OUTPUT)

kapasyatina
() автор топика
Ответ на: комментарий от kapasyatina

>на гейт внешнего интерфейса
O_o
на внешний интерфейс гейта?
на интерфейс внешнего гейта?

пакеты мои, как пролезают

О БОЖЕ! СПАСАЙСЯ, КТО МОЖЕТ! Каждый сам за себя!!!!111

очевидно ошибки в nat скрипте

Я так не думаю

Нарисуйте сначала, а то нифига не понятно.

markevichus ★★★
()

>> iptables -A FORWARD -p TCP -i eth1 --source 192.168.0.0/24 --destination 0.0.0.0/0 --match state --state NEW,ESTABLISHED -j ACCEPT

а разве это правило не разрешает прохождение NEW-пакетов?

nixtrian ★
()

> iptables -t nat -A POSTROUTING -p TCP -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 10.1.1.1

наружу переодически падают icmp пакеты от 192.168.x.x, why?

Например потому, что 192.168.1.1 не попадает в 192.168.0.0/24, и значит пакеты с этого адрес не попадают под SNAT?

Nastishka ★★★★★
()
Ответ на: комментарий от kapasyatina

> пакеты мои, как пролезают через 10.1.1.1 (мой шлюз) непонятно. очевидно ошибки в nat скрипте...

Нет, через ошибки в правилах файрвола, сделанные Вами: в правиле написано -p tcp, а пакет из протокола относится к протоколу icmp. Естественно, он не попадет под правило SNAT.

УБЕРИТЕ -p tcp ИЗ ПРАВИЛА SNAT

Nastishka ★★★★★
()

да. кстати, в lartc сказано, что в цепочке *nat трафик фильтруется только в крайних случаях

nixtrian ★
()
Ответ на: комментарий от Nastishka

>Нет, через ошибки в правилах файрвола, сделанные Вами: в правиле написано -p tcp, а пакет из протокола относится к протоколу icmp. Естественно, он не попадет под правило SNAT.

Там в форварде заблокированы все протоколы, кроме TCP.

А ситуация такая, что кто-то из сети 10.0.0.0/8 (возможно, что и не топикстартер) пропускает к шлюзу 10.1.1.2 некие TCP или UDP пакеты из сети 192.168.0.0/24, на которые шлюз отвечает icmp destination-unreachable admin-prohibit.

nnz ★★★★
()
Ответ на: комментарий от markevichus

>Нарисуйте сначала, а то нифига не понятно.

ok попытаюсь

$ cat /etc/network/interfaces

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

address 10.1.1.1

netmask 255.0.0.0

network 10.0.0.0

broadcast 10.255.255.255

gateway 10.1.1.2

auto eth1

iface eth1 inet static

address 192.168.0.1

netmask 255.255.255.0

далее после запуска скрипта из первого поста:

# iptables -v -L FORWARD

Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

0 0 ACCEPT tcp  — eth1 any 192.168.0.0/24 anywhere state NEW,ESTABLISHED

0 0 ACCEPT tcp  — eth0 any anywhere 192.168.0.0/24 state ESTABLISHED

то есть, наружу выпускаем только tcp трафик.

изначально было -p all, и в моем понимании если icmp пакеты транслируются, то после трансляции у них в поле адрес источника должно стоять 10.1.1.1 (мой внешний интерфейс)

10.1.1.2 - шлюз провайдера, на него доступ не имею, соответственно играться и мониторить результат не могу.

выяснилось, что на 10.1.1.2 приходят icmp пакеты с адресами из диапазона 192.168.0.0/24 (лог в сообщении от 28.05)

пакеты от меня,ибо если ifconfig eth0 down, то все ок.

поставил в скрип -p tcp - ситуация не изменилась.

вопрос:

1. почему при -p all у icmp пакетов адрес источника 192.168.0.x а не 10.1.1.1?

2. почему при -p tcp icmp траффик впринципе проходит, ведь политика по умолчанию в FORWARD - DROP?

kapasyatina
() автор топика
Ответ на: комментарий от nixtrian

> да. кстати, в lartc сказано, что в цепочке *nat трафик фильтруется только в крайних случаях

расшифруйте плиз. как это относится к моему случаю, что то непоиму...

kapasyatina
() автор топика
Ответ на: комментарий от Nastishka

>Нет, через ошибки в правилах файрвола, сделанные Вами: в правиле написано -p tcp, а пакет из протокола относится к протоколу icmp. Естественно, он не попадет под правило SNAT.

УБЕРИТЕ -p tcp ИЗ ПРАВИЛА SNAT

было желание пускать только tcp, соответственно, что непопало под мое правило - должно попасть под правило по умолчанию, что есть DROP. или нет?)

kapasyatina
() автор топика
Ответ на: комментарий от kapasyatina

ну это было к тому, что как правило в цепочке «нат» трафик не фильтруется как у тебя: `iptables -t nat -A POSTROUTING -p TCP -o eth0 -s 192.168.0.0/24 -j SNAT --to-source 10.1.1.1`

для фильтрации есть цепочка «filter»

Фильтрация в этой цепочке используется только в крайнем случае. У меня такой был, пров не настроил порт-сплиттинг для дсл и если назначить адрес машине в «популярной подсети», то, вероятнее всего в подсети появятся еще машинки (тут подробнее http://www.linux.org.ru/forum/admin/4432831 )

Ну и у тебя, по всей видимости, ситуация тоже нетривиальная.

10.1.1.2 - шлюз провайдера, на него доступ не имею, соответственно играться и мониторить результат не могу.

Кстати.. чтобы как-то проконтролировать весь этот трафик, могу посоветовать сделать другой шлюз (временно), на который будет доступ и посмотреть.

nixtrian ★
()
Ответ на: комментарий от kapasyatina

посмотри вывод iptables-save, оно информативнее и нагляднее(подчас) чем iplables -L

nixtrian ★
()

Конечно не по теме немного, но все таки скажу.

Лучше вместо этого: --match state --state NEW,ESTABLISHED
Использовать: -m conntrack --ctstate NEW,ESTABLISHED

static ★★
()
Ответ на: комментарий от kapasyatina

>пакеты от меня,ибо если ifconfig eth0 down, то все ок.

Если пакеты идут постоянно, то посмотрите их tcpdump'ом, «tcpdump -i eth0 -n -nn -v icmp».

1. почему при -p all у icmp пакетов адрес источника 192.168.0.x а не 10.1.1.1?

Дак у вас там в SNAT-правиле "-p all" или "-p tcp"? И, может я и ошибаюсь, но если ping работает непрерывно, то conntrack считает это всё одной сессией и изменение в POSTROUTING не окажет на SNAT этой сессии влияния, так как это правило только для "--state NEW".

2. почему при -p tcp icmp траффик впринципе проходит, ведь политика по умолчанию в FORWARD - DROP?

Значит icmp-пакеты идут от вашего сервера. Кстати, как вы им управляете, если у вас «iptables -P INPUT DROP» и «iptables -P OUTPUT DROP»?

mky ★★★★★
()
Ответ на: комментарий от nixtrian

вроде как понимание пришло, всем спасибо ))

в ветке все сообщения по делу, надо было только их осмыслить...

зло в желании фильтровать трафик в nat, как правильно заметил nixtrian и в непонимании работы iptables..

сейчас tcpdump обещает долгую и счастливую жизнь.

kapasyatina
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Целесообразно ли запускать KVM виртуализацию и виртуальную клатеризацию внутри сервера со следующими характеристиками?
Admin
Debian Lenny + Samba + LDAP: проблема добавления пользователя →