[lexalex]

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

Вкратце: каким образом пакеты могут НЕ 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 June 12, 2017 by lexalex

[myth]

А по-нормальному сделать сразу?

[pppoetest]

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

 

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

 

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

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

[lexalex]

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

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

 

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

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

[[anp/hsw]]

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

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

[nuclearcat]

Подсказка

-m conntrack --ctstate INVALID -j DROP

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

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

 

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

[lexalex]

"Проблемный хост" (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 June 13, 2017 by lexalex

[nuclearcat]

Я так понимаю 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

[lexalex]

nuclearcat

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

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

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

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

[nuclearcat]

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

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