LINUX.ORG.RU
ФорумAdmin

Не работает NAT Трансляция.

 , , ,


0

1

Некоректно отрабатывает нат трансляция. Вот есть роутер 172.17.0.1 у него есть LAN и WAN и WG (Nederland) Задача открыть доступ через WAN (172.17.0.3:5900) который в локалке находится. Но при этом весь трафик на роутере (172.17.0.1) по правилу идет в WG (Nederland) через 10.10.10.1 Правило

ip rule list
0:      from all lookup local
1:      from 172.16.0.3 lookup nederland
29998:  from all fwmark 0x20000/0xff0000 lookup pbr_wan
30000:  from all fwmark 0x10000/0xff0000 lookup pbr_nederlands
32766:  from all lookup main
32767:  from all lookup default

Таблица:

ip route show table nederland
default dev nederlands proto static scope link metric 2
10.9.9.0/24 dev wgserver proto static scope link metric 1
192.168.0.0/16 dev wgserver proto static scope link metric 1
192.168.4.0/24 dev br-lan proto static scope link

Так ну очевидно что нат нужно добавить для входящего трафика от wan. Иначе все ответы будут идти через WG (Nederland) 10.10.10.1 он же дефолтный. Добавляем:

OpenWrt

И видим такую странную картину в wireshark те адрес подменяется но обратно не проходят. Wiresgark



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

Какие правила маркировки? Возможно ответ бегает по кругу в таблице nederland пока у него не закончится ttl, т.к. из этой таблицы отсутствует маршрут в WAN

Khnazile ★★★★★
()
Последнее исправление: Khnazile (всего исправлений: 1)
Ответ на: комментарий от Khnazile

Ну так разве, ответ не должен попасть в nat таблицу на роутере (mascarding). Вот он пришел пакет из WAN ему адрес источника подменился на локальный и ответный пакет уже через нат-таблицу идет?

Loafter
() автор топика

Так ну очевидно что нат нужно добавить для входящего трафика от wan.

Не знаю, что вам там очевидно, но contrack происходит до routing decision. Поэтому на момент выбора маршрута у вас будут пакеты 172.17.0.3:5900->A.B.C.D:X, а не 172.17.0.3:5900->172.17.0.1:X

То, что вы хотите решается маршрутизацией на основе маркировки пакетов, либо по порту 5900, либо через save-mark /restore-mark.

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

Да именно порт 5900 (Усоловно) Грубо говоря мне нужно что бы весь трафик с машины 172.17.0.3 шел через нидерланды. Кроме того который пришел на 5900 порт он ответом должен идти через WAN интерфейс.

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

Ну, макрируете все пакеты с src 172.17.0.3:5900 и отправляет их, как я понял, в таблицу pbr_wan. Только правило должно быть до:

1: from 172.16.0.3 lookup nederland

То есть как-то так:

# ip rule del from 172.16.0.3 lookup nederland
# iptables -t mangle -A PREROUTING -p tcp -s 172.17.0.3 --sport 5900 -j MARK --set-mark 2
# ip rule add fwmark 2 priority 10 table pbr_wan
# ip rule add from 172.16.0.3 priority 20 table nederland

Как это правильно прописывать в OpenWrt, чтобы сохранилось при перезагрузке не знаю.

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

Так вроде правило применяется 240 байт прошло.

Traffic matched by rule: 4 Packets, 240 Bytes
Source IP is 172.16.0.3 TCP source port is 10500 Set header field Packet mark to 2

но по чему то все рано идет TCP Retransmission для обратных пакетов

0:      from all lookup local
1:      from 172.16.0.3 lookup nederland
2:      from all fwmark 0x2 lookup main
32766:  from all lookup main
32767:  from all lookup default
default via 192.168.1.254 dev eth1 proto static
default dev nederlands proto static scope link metric 2
10.7.7.1 dev wgserver proto static scope link metric 1
10.8.8.1 dev wgserver proto static scope link metric 1
10.9.9.0/24 dev wgserver proto static scope link metric 1
10.9.9.2 dev wgserver proto static scope link metric 1
10.9.9.3 dev wgserver proto static scope link metric 1
10.9.9.5 dev wgserver proto static scope link metric 1
10.9.9.6 dev wgserver proto static scope link metric 1
10.9.9.7 dev wgserver proto static scope link metric 1
10.9.9.8 dev wgserver proto static scope link metric 1
10.9.9.14 dev wgserver proto static scope link metric 1
10.9.9.18 dev wgserver proto static scope link metric 1
10.10.10.0/24 dev nederlands proto static scope link metric 2
10.10.10.3 dev nederlands proto static scope link metric 2
10.96.69.0/24 dev tun0 proto kernel scope link src 10.96.69.95
95.140.147.128 via 192.168.1.254 dev eth1 proto static
172.16.0.0/16 dev docker1 proto kernel scope link src 172.16.0.1
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.2
192.168.2.0/24 dev wgserver proto static scope link metric 1
192.168.3.0/24 dev wgserver proto static scope link metric 1
192.168.4.0/24 dev br-lan proto kernel scope link src 192.168.4.1
192.168.5.0/24 dev wgserver proto static scope link metric 1
192.168.6.0/24 dev wgserver proto static scope link metric 1
192.168.7.0/24 dev wgserver proto static scope link metric 1
192.168.8.0/24 dev wgserver proto static scope link metric 1
192.168.123.0/24 via 10.96.69.1 dev tun0

Или тут приоритет уже срабатывает

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

Вот зараза все равно не срабатывает. Как бы это все отладить из за чего это можеть быть?

0	from all lookup local
1	from 172.16.0.3 fwmark 0x2 lookup main
2	from 172.16.0.3 lookup nederland
32766	from all lookup main
32767
Loafter
() автор топика
Ответ на: комментарий от Loafter

Не срабатывает, так как пакет не туда уходит? tcpdump на wan интерфейсе не видит уходящие от 172.16.0.3 пакеты с этого порта?

В iptables в FORWARD эти пакеты разрешены?

Можно в iptables временно выткать правила без цели, чтобы только счётчики срабатывали. Что-то типа:

iptables -I FORWARD -s 172.17.0.3 --sport 5900

iptables -I FORWARD -s 172.17.0.3 --sport 5900 -o WAN_interface

Потом пытаться что-то передать и смотреть счётчики. Если у обоих правил счётчики растут, значит маршрутизация работает правильно и пакет рубится где-то в iptables. А если у -o WAN правила нулевые счётчики, значит что-то с маршрутизацией. Либо пакет не маркируются, либо в таблице main что-то не то написано.

mky ★★★★★
()