Jump to content
Калькуляторы

пакеты мимо SNAT iptables'а Подскажите, уважаемые сетевики-никсоиды

Столкнулся вот... моих знаний не хватает - прошу подсказать и научить.

Вкратце: каким образом пакеты могут НЕ SNATиться на выходе, при безусловном указании правила?

Как это продиагностировать и поподробнее отследить?

 

Чуть подробнее.

(сеть1) (сеть2)

I I

хост1 -(сеть12)- хост2 -(сеть23)- хост3 -(сеть34)- хост4

 

всё давно настроено и работает, но вот недавно пришлось "заплатку на заплатку" сделать:

пакет(пинг) от хост4 идет в сеть2 ЧЕРЗ(!!) хост1 (да, так и надо) и на выходе из хост2 в сеть2 СНАТ/МАСКАРАД НЕ(!) отрабатывает

но

если без захода на хост1 (маршрутизация по условиям), то те-же самые правила СНАТа/МАСКАРАДа работают.

Наблюдал с помощью тисипидампа. (Изменеия в заголовки на хост1 не вносятся).

"Схему" прошу не критиковать - так исторически сложилось.

Более подробно... сложно объяснить; чтоб всё и сразу.

хост1, 2 и 3 - линуксы;

хост2 (на котором трабл) - конкретно убунта 14.04

Прошу помочь/подсказать/направить.

 

upd:

rp_filter = 0

Edited by lexalex

Share this post


Link to post
Share on other sites

Я бы потратил чуть больше времени на приведение сети в порядок, чем искать костыли, которые, по любому, в будущем окажутся граблями.

 

По сабжу, никаких сетей, таблиц и правил маршрутизации, ната/маскарадинга не указано ни на одном из хопов, какой помощи вы ждёте?

 

Вкратце: каким образом пакеты могут НЕ SNATиться на выходе, при безусловном указании правила?

Один из напримеров: Если правилами маршрутизации пакет переправлен на интерфейс на котором нат не выполняется.

Share this post


Link to post
Share on other sites

По сабжу, никаких сетей, таблиц и правил маршрутизации, ната/маскарадинга не указано ни на одном из хопов, какой помощи вы ждёте?

Согласен. Постараюсь...

 

Один из напримеров: Если правилами маршрутизации пакет переправлен на интерфейс на котором нат не выполняется.

Насколько я знаю, (построутинг)снат/маскарад работает ПОСЛЕ маршрутизации. - Нет? ("почему-то_не_СНАТченый" пакет ловится тисипидамноп на ВЫХОДЕ нужного/правильного интерфейса)

Share this post


Link to post
Share on other sites

Нужно пару примеров таких пакетов, и дамп правил iptables.

Без этого - гадание на кофейной гуще.

Share this post


Link to post
Share on other sites

Подсказка

-m conntrack --ctstate INVALID -j DROP

например в forward, только осторожно.

Например повторные TCP RST от оборванных соединений оно натить не будет, возможно их вы и видите, проверьте по tcpdump

 

Если же у вас не натится пинг - скорее всего у вас бардак в правилах, тут кроме как приводить в порядок, других рецептов нет.

Share this post


Link to post
Share on other sites

"Проблемный хост" (2) с Ubuntu x64 14.04.5 LTS (даже обновил/перегрузил)

eth0 с белым ИП

tap381 смотрит на хост1

tap382 смотрит на хост3 (за которым сеть 172.16.0.0/12)

на хост3 ТОСятся пакеты которые надо пустить на хост1

в некоторых случаях (как в примере) хост1 возвращает пакеты обратно (только теперь без меток, для обработки правилами по-умолчанию)

("все имена вымышлены, совпадения случайны", что никак не влияет на суть)

 

# ifconfig

eth0 Link encap:Ethernet HWaddr 00:50:56:8e:33:b2

inet addr:85.7.8.200 Bcast:85.7.8.255 Mask:255.255.255.128

inet6 addr: fe80::250:56ff:fe8e:33b2/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:1114280 errors:0 dropped:12 overruns:0 frame:0

TX packets:1038570 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:759458219 (759.4 MB) TX bytes:766781366 (766.7 MB)

 

tap381 Link encap:Ethernet HWaddr e6:d9:bc:11:28:0f

inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.255.0

inet6 addr: fe80::e4d9:bcff:fe11:280f/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:184263 errors:0 dropped:4190 overruns:0 frame:0

TX packets:165757 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:144077020 (144.0 MB) TX bytes:72492348 (72.4 MB)

 

tap382 Link encap:Ethernet HWaddr 36:06:88:6e:10:d1

inet addr:192.168.254.130 Bcast:192.168.254.255 Mask:255.255.255.128

inet6 addr: fe80::3406:88ff:fe6e:10d1/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:328716 errors:0 dropped:0 overruns:0 frame:0

TX packets:551292 errors:0 dropped:221 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:47665921 (47.6 MB) TX bytes:593595477 (593.5 MB)

 

хост2# iptables-save

# Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017

*mangle

:PREROUTING ACCEPT [764209:490874488]

:INPUT ACCEPT [370734:192398404]

:FORWARD ACCEPT [389679:296731296]

:OUTPUT ACCEPT [392886:319617251]

:POSTROUTING ACCEPT [782565:616348547]

-A PREROUTING -m tos --tos 0x08/0xff -j MARK --set-xmark 0x8/0xffffffff

-A PREROUTING -m mark --mark 0x8 -j TOS --set-tos 0x00/0xff

COMMIT

# Completed on Tue Jun 13 13:56:38 2017

# Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017

*filter

:INPUT ACCEPT [912:218860]

:FORWARD ACCEPT [1096:685248]

:OUTPUT ACCEPT [968:660852]

COMMIT

# Completed on Tue Jun 13 13:56:38 2017

# Generated by iptables-save v1.4.21 on Tue Jun 13 13:56:38 2017

*nat

:PREROUTING ACCEPT [25410:3343645]

:INPUT ACCEPT [11991:852469]

:OUTPUT ACCEPT [1099:75346]

:POSTROUTING ACCEPT [6319:417929]

-A POSTROUTING -s 192.168.254.128/28 -o eth0 -j MASQUERADE

-A POSTROUTING -s 172.16.8.0/23 -o eth0 -j MASQUERADE

-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

COMMIT

# Completed on Tue Jun 13 13:56:38 2017

 

хост2# ip ro ls

default via 85.7.8.129 dev eth0

172.16.0.0/12 via 192.168.254.129 dev tap382

85.7.8.128/25 dev eth0 proto kernel scope link src 85.7.8.200

192.168.1.0/24 dev tap381 proto kernel scope link src 192.168.1.253

192.168.254.128/25 dev tap382 proto kernel scope link src 192.168.254.130

 

хост2# ip ru ls

0: from all lookup local

32765: from all fwmark 0x8 lookup tbl1

32766: from all lookup main

32767: from all lookup default

 

хост2# ip ro ls table tbl1

default via 192.168.1.254 dev tap381

172.16.0.0/12 via 192.168.254.129 dev tap382

 

 

хост1# ping 5.55.55.55 -c 1

хост3# ping 5.55.55.55 -c 1

 

хост2# tcpdump -i eth0 -n host 5.55.55.55 -v

 

15:21:18.580757 IP (tos 0x0, ttl 63, id 4206, offset 0, flags [DF], proto ICMP (1), length 84)

85.7.8.200 > 5.55.55.55: ICMP echo request, id 37926, seq 0, length 64

15:21:18.581689 IP (tos 0x0, ttl 60, id 59255, offset 0, flags [none], proto ICMP (1), length 84)

5.55.55.55 > 85.7.8.200: ICMP echo reply, id 37926, seq 0, length 64

 

15:21:29.630214 IP (tos 0x0, ttl 61, id 49683, offset 0, flags [DF], proto ICMP (1), length 84)

192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64

 

 

хост2# tcpdump -i tap381 -n host 5.55.55.55 -v

 

15:21:18.580708 IP (tos 0x0, ttl 64, id 4206, offset 0, flags [DF], proto ICMP (1), length 84)

192.168.1.254 > 5.55.55.55: ICMP echo request, id 37926, seq 0, length 64

15:21:18.581708 IP (tos 0x0, ttl 59, id 59255, offset 0, flags [none], proto ICMP (1), length 84)

5.55.55.55 > 192.168.1.254: ICMP echo reply, id 37926, seq 0, length 64

 

15:21:29.613981 IP (tos 0x0, ttl 63, id 49683, offset 0, flags [DF], proto ICMP (1), length 84)

192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64

15:21:29.630205 IP (tos 0x0, ttl 62, id 49683, offset 0, flags [DF], proto ICMP (1), length 84)

192.168.254.129 > 5.55.55.55: ICMP echo request, id 1522, seq 1, length 64

 

т.е.

пинг с хост1 проходит и ответ возвращается

пинг с хост3 (после захода на хост1) уходит мимо МАСКАРАДа

 

 

net.ipv4.conf.*.send_redirects

было 1, теперь 0 (дефолтный и для каждого интерфейса) - без изменений

Edited by lexalex

Share this post


Link to post
Share on other sites

Я так понимаю 15:21:29.613981 пакет ушел через tap и вернулся через него 15:21:29.630205, таким образом проходя хост2 дважды?

Если да, то честно говоря у вас очень замороченная схема, и чтобы она работала как положено, вам нужно очень хорошо понимать как работает conntrack.

В вашем случае, кроме

-A PREROUTING -m tos --tos 0x08/0xff -j MARK --set-xmark 0x8/0xffffffff

вам скорее всего понадобится, чтобы conntrack не видел пакет, который будет проходить через этот хост первый раз

-t raw -A PREROUTING -m tos --tos 0x08/0xff -j CT --notrack

Share this post


Link to post
Share on other sites

nuclearcat

Да, отключение коннтрака помогло, спасибо!

(iptables -t raw -A PREROUTING -m tos --tos 0x08/0xff -j NOTRACK)

Не будет ли теперь проблем в случае однократного(!) прохождения хост2? (когда хост1 сам доставит пакет на "5.55.55.55")

И всеж хотелось бы понять: что и как настроить в коннтраке чтоб он корректно обрабатывал... мой случай? - Тоже буду признателен :)

Share this post


Link to post
Share on other sites

Проблем не должно быть, т.к. когда пакет проходит однажды, у вас нет tos, а в этом случае NOTRACK не срабатывает

Ваш случай неправилен для conntrack, потому и надо такой костылинг. Если пинг прошел, то он отмечается в conntrack и при повторном проходе оно его не будет трогать и делать ему MASQUERADE, нужно дебажить, но или оно его видит как дубликат старого или же вообще идет как INVALID.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this