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

NAT не транслирует пакеты FIN / RST

 , ,


0

1

Доброго времени!

Есть инсталляция роутера BGP + NAT на одной машине. С одной стороны машина подключена к серой сети, с другой 2 выхода в интернет. CentOS 6.6

NAT очевидно работает, в данный момент пропуская гигабит трафика.

Однако, почему то происходит так, что в интернет уходят пакеты с серыми адресами источника, с запросами на завершение соединений, а так же некоторые ICMP, типа host unreachable.

При этом, общее правило iptables в таблице nat, после всех правил SNAT, нацеленное на всё серое пространство, не совпадает с этими пакетами.

Кто-то сталкивался ?

UPD:

iptables -t nat -A POSTROUTING -p tcp -s 10.20.30.0/24 -j SNAT --to-source xxx.xxx.xxx.xx1
iptables -t nat -A POSTROUTING -p udp -s 10.20.30.0/24 -j SNAT --to-source xxx.xxx.xxx.xx1
iptables -t nat -A POSTROUTING -p icmp -s 10.20.30.0/24 -j SNAT --to-source xxx.xxx.xxx.xx1

iptables -t nat -A POSTROUTING -p tcp -s 10.20.31.0/24 -j SNAT --to-source xxx.xxx.xxx.xx2
iptables -t nat -A POSTROUTING -p udp -s 10.20.31.0/24 -j SNAT --to-source xxx.xxx.xxx.xx2
iptables -t nat -A POSTROUTING -p icmp -s 10.20.31.0/24 -j SNAT --to-source xxx.xxx.xxx.xx2

iptables -t nat -A POSTROUTING -p tcp -s 10.20.32.0/24 -j SNAT --to-source xxx.xxx.xxx.xx3
iptables -t nat -A POSTROUTING -p udp -s 10.20.32.0/24 -j SNAT --to-source xxx.xxx.xxx.xx3
iptables -t nat -A POSTROUTING -p icmp -s 10.20.32.0/24 -j SNAT --to-source xxx.xxx.xxx.xx3

iptables -t nat -A POSTROUTING -p tcp -s 10.20.0.0/16 -j SNAT --to-source xxx.xxx.xxx.xx4
iptables -t nat -A POSTROUTING -p udp -s 10.20.0.0/16 -j SNAT --to-source xxx.xxx.xxx.xx4
iptables -t nat -A POSTROUTING -p icmp -s 10.20.0.0/16 -j SNAT --to-source xxx.xxx.xxx.xx4

При этом, общее правило iptables в таблице nat, после всех правил SNAT, нацеленное на всё серое пространство, не совпадает с этими пакетами. 

Нераспарсил. Давай свою партянку правил.

pyatak123 ()
Последнее исправление: pyatak123 (всего исправлений: 1)

Так все таки я не понял , что за общее правило которое

общее правило iptables в таблице nat, после всех правил SNAT, нацеленное на всё серое пространство

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

запустил tcpdump -i eth4 'net 10.20.0.0/16' и вижу не слишком большую, но кучу RST и FIN пакетов из указанной подсети, например:

17:21:57.563450 IP 10.20.36.172.52963 > cds970.iad.llnw.net.http: Flags [R], seq 3271160863, win 0, length 0
17:21:57.563452 IP 10.20.36.172.52963 > cds970.iad.llnw.net.http: Flags [R], seq 3271160863, win 0, length 0
17:21:57.563533 IP 10.20.36.172.52963 > cds970.iad.llnw.net.http: Flags [R], seq 3271160863, win 0, length 0
17:21:57.564312 IP 10.20.36.172.52963 > cds970.iad.llnw.net.http: Flags [R], seq 3271160863, win 0, length 0
17:21:57.616178 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.616194 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.616382 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.616388 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.616421 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.616516 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.618073 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.619443 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.619479 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.619528 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.619653 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.619658 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.620226 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.620306 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.620312 IP 10.20.39.88.60820 > a92-122-212-35.deploy.akamaitechnologies.com.http: Flags [R], seq 3862110059, win 0, length 0
17:21:57.681281 IP 10.20.33.105.innosys-acl > ip118.156.odnoklassniki.ru.http: Flags [F.], seq 0, ack 1, win 32768, length 0
17:21:57.881110 IP 10.20.50.217.62597 > 119.81.57.82-static.reverse.softlayer.com.http: Flags [F.], seq 0, ack 1, win 65535, length 0
17:21:57.979532 IP 10.20.39.88.60784 > instagram-shv-01-ams3.fbcdn.net.https: Flags [R], seq 1821423867, win 0, length 0

invertor ()
Ответ на: комментарий от pyatak123

eth4 да, этот ифейс смотрит в инет, дело в том, что уходящие с него пакеты должны быть с транслированными адресами, 10.20.0.0/16 не должны с него уходить.

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

Попробуй из правил убрать явное указание протокола (tcp,udp,icmp) оставь только адрес (-s) , это конечно пальцем в небо , но все таки.
Поставь conntrack и посмотри , не упираешься ли в лимит соединений.

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

Разделение на протоколы внёс уже для эксперимента, при спецификации -p all и даже без неё, всё было точно так же. Conntrack конечно же стоит и до лимита ещё далеко.

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

Может быть проблема в том что данные пакеты маркируются как INVALID , то nat их не обработает.
Попробуй залогируй первым правилом -m state INVALID -j LOG, просто посмотреть не они ли.

pyatak123 ()
Ответ на: комментарий от invertor

А сделай (для сравнения) дамп в котором будет и норм трафик и не норм трафик.

pyatak123 ()
Ответ на: комментарий от invertor

где-то в начале filter/FORWARD нужно

iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state NEW -p tcp ! --syn -j DROP

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

Кстати действительно помогло, достаточно первого правила

iptables -A FORWARD -m state --state INVALID -j DROP

Возможно конечно что это баги клиентских операционок. Или чудо-фаерволов с антивирусами. Но вдруг это проблема трассировщика соединений, который почему-то считает что вполне штатные запросы на завершение соединений ! RELATED.

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

Хотя я не заметил роста зависших в воздухе соединений.

invertor ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.