LINUX.ORG.RU
Форум — Admin  

Iproute2+iptables DNAT


0

1

Есть проблема с пробросом пакета в локалку пришедшего на второй канал, если маршрут по умолчанию смотрит а первый канал. Ситуация классическая:
Сервер убунту 10.04. На нем:
локалка 192.168.60.0/24 подключенная к eth1(192.168.60.4)
Два канала инет:
1. ххх.ххх.ххх.32/29 заходит на eth0(xxx.xxx.xxx.35), eth0:1(xxx.xxx.xxx.36), шлюз у провайдера xxx.xxx.xxx.33
2. yyy.yyy.yyy.0/24 заходит на eth2(yyy.yyy.yyy.2), шлюз у провайдера yyy.yyy.yyy.1 (Он же является шлюзом по умолчанию).

Для работы через два канала сделано в iproute2 следующее:
# cat /etc/iproute2/rt_tables
255 local
254 main
253 default
0 unspec

332 flex.inet
333 rostelecom.inet

Настройка таблиц и маршрутов:

ip route flush table flex.inet
ip route flush table rostelecom.inet

ip route add xxx.xxx.xxx.32/29 dev eth0 src xxx.xxx.xxx.35 table flex.inet
ip route add default via xxx.xxx.xxx.33 table flex.inet
ip route add xxx.xxx.xxx.32/29 dev eth0 src xxx.xxx.xxx.35
ip rule add from xxx.xxx.xxx.35 table flex.inet
ip rule add from xxx.xxx.xxx.36 table flex.inet

ip route add yyy.yyy.yyy.0/24 dev eth2 src yyy.yyy.yyy.2 table rostelecom.inet
ip route add default via yyy.yyy.yyy.1 table rostelecom.inet
ip route add yyy.yyy.yyy.0/24 dev eth2 src yyy.yyy.yyy.2
ip rule add from yyy.yyy.yyy.2 table rostelecom.inet

ip route add 127.0.0.0/8 dev lo table flex.inet
ip route add 127.0.0.0/8 dev lo table rostelecom.inet

ip route add 192.168.60.0/24 dev eth1 table flex.inet
ip route add 192.168.60.0/24 dev eth1 table rostelecom.inet

ip route add yyy.yyy.yyy.0/24 dev eth2 table flex.inet
ip route add xxx.xxx.xxx.32/29 dev eth0 table rostelecom.inet

ip route flush cache

Оба интерфейса сервера доступны из интернет по обоим каналам и из локалки. Мне нужно пробросить порт RDP с двух внешних айпишников (35 и 36) на, соответственно два хоста в локалке (60.1 и 60.3). Для этого в iptables сделал следующее:

echo «1» > /proc/sys/net/ipv4/ip_forward

-A PREROUTING -d xxx.xxx.xxx.35/32 -i eth0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.60.1
-A PREROUTING -d xxx.xxx.xxx.36/32 -i eth0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.60.3

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.60.1/32 -i eth0 -j ACCEPT
-A FORWARD -d 192.168.60.3/32 -i eth0 -j ACCEPT

-A POSTROUTING -d 192.168.60.1/32 -j ACCEPT
-A POSTROUTING -d 192.168.60.3/32 -j ACCEPT
-A POSTROUTING -o eth0 -j SNAT --to-source xxx.xxx.xxx.35
-A POSTROUTING -o eth2 -j SNAT --to-source yyy.yyy.yyy.2
-A POSTROUTING -o eth1 -j SNAT --to-source 192.168.60.4


Проблема заключается в том, что проброс портов нормально работает только тогда, когда шлюз по умолчанию смотрит в xxx.xxx.xxx.33 а иначе - пакет приходит в цепочку PREROUTING, DNATится и потом уходит непонятно куда в FORWARD уже не попадая... Я понимаю, что проблема в роутинге, но где именно - ума не приложу. Буду очень благодарен за совет.


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

Да, не написал в условии, это сделано.

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

>пакет приходит в цепочку PREROUTING, DNATится и потом уходит непонятно куда в FORWARD уже не попадая...

Как проверял?

Одну потенциальную проблему я вижу: ответ может уходить не тем маршрутом, которым пришел, и соответственно, SNAT'иться на другой айпишник. Советую в mangle/PREROUTING делать CONNMARK --set-mark для пробрасываемых соединений, затем CONNMARK --restore-mark для всех пакетов от 192.168.60.1,192.168.60.3 и соответствующее ip rule. В nat/PREROUTING можно уже по -m connmark.

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

Как проверял?


# iptables-save -c | grep 192.168.60.1
[16:832] -A PREROUTING -d xxx.xxx.xxx.35/32 -i eth0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.60.1
[0:0] -A FORWARD -d 192.168.60.1/32 -i eth0 -j ACCEPT

Одну потенциальную проблему я вижу: ответ может уходить не тем маршрутом, которым пришел, и соответственно, SNAT'иться на другой айпишник.


Я смотрел trafshow (tcpdump) - пакет не доходит в прямом направлении до интерфейса локалки (eth1). Т.е. он теряется между прероутингом и фильтром форвард - на первой маршрутизации.

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

>Я смотрел trafshow (tcpdump) - пакет не доходит в прямом направлении до интерфейса локалки (eth1). Т.е. он теряется между прероутингом и фильтром форвард - на первой маршрутизации.

Так себя обычно rp_filter ведет.

А обратно (к инициатору соединения) никаких icmp-сообщений не отправляется?

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

Делаю:
telnet xxx.xxx.xxx.35 3389

Имею на интерфейсе:
# tcpdump -i eth0 -n host xxx.xxx.xxx.35
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:49:56.250401 ARP, Request who-has xxx.xxx.xxx.33 tell xxx.xxx.xxx.35, length 28
13:49:56.250990 ARP, Reply xxx.xxx.xxx.33 is-at 00:13:c3:43:c1:d1, length 46
13:49:58.778143 IP 80.91.175.35.37222 > xxx.xxx.xxx.35.3389: Flags [S], seq 1616145226, win 5840, options [mss 1460,sackOK,TS val 9818380 ecr 0,nop,wscale 6], length 0
13:50:01.785606 IP 80.91.175.35.37222 > xxx.xxx.xxx.35.3389: Flags [S], seq 1616145226, win 5840, options [mss 1460,sackOK,TS val 9818680 ecr 0,nop,wscale 6], length 0
13:50:07.765505 IP 80.91.175.35.37222 > xxx.xxx.xxx.35.3389: Flags [S], seq 1616145226, win 5840, options [mss 1460,sackOK,TS val 9819280 ecr 0,nop,wscale 6], length 0
13:50:39.247065 IP 80.91.175.35 > xxx.xxx.xxx.35: ICMP echo request, id 512, seq 41778, length 40
13:50:39.247172 IP xxx.xxx.xxx.35 > 80.91.175.35: ICMP echo reply, id 512, seq 41778, length 40

80.91.175.35 - мой айпи.

При этом тисипидамп висящий на двух оставшихся интерфейсах и монитрорящий «мой айпи» - молчит.

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

Nov 2 14:11:31 ubuntu kernel: [73250.287377] martian source 192.168.60.1 from 80.91.175.35, on dev eth0

Nov 2 14:11:37 ubuntu kernel: [73256.283137] martian source 192.168.60.1 from 80.91.175.35, on dev eth0

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

Вот блин... А я так надеялся. что у меня глаз «замылился» и я какой-то простой и очевидной вещи усматриваю в конфигах. Вроде ж достаточно тривиальнная задача.

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

>[0:0] -A FORWARD -d 192.168.60.1/32 -i eth0 -j ACCEPT

Попробуй добавить это правило первым (-I вместо -A) и повторить эксперимент. Возможно, пакеты пропускаются по вышеидущим правилам.

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

У меня все правила добавляются одним скриптом. Оно стоит достаточно высоко. Я ставил самым первым .... -j ULOG --ulog-prefix «forward to 60.1» - в лог ничего не попадало.

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