LINUX.ORG.RU

[iptables] yota, прокси, SNAT на другой интерфейс

 


0

0

Всем привет!

Имеется:

          +-------+
 eth0 ----+       |
          |       |
          |       +---- eth4 (192.168.0.55)
          |       |
 eth1 ----+       |
          +-------+

eth0, eth1 - смотрят в интернет, policy based routing работает eth4 - смотрит в LAN.

На хосте крутится squid, который соответственно лезет в интернет через eth0/1.

Траффик дорогой. Купили yota-роутер, т.к. свисток не достаточно стабилен.

Кидаем часть проксевого траффика на yota через сквид, через дочерний прокси, который работает на отдельной машинке в LAN и там шлюзом стоит yota-роутер (192.168.0.251).

Отдельная машинка это не гуд, можно конечно и в виртуальную закинуть, но хочется разрулить все на одном хосте. Думаю все просто, надо еще один прокси поднять, для него сделать свою табличку маршрутизации, назовем ее T4:

pluto ~ # ip route show table T4
default via 192.168.0.251 dev eth4 
Теперь как бы в нее траффик завернуть? Ага, через fwmark:
pluto ~ # ip rule add from all fwmark 0x450 lookup T4
pluto ~ # iptables -t mangle -A OUTPUT -m owner --uid-owner 1104 -j MARK --set-mark 1104
Под uid 1104 работает tinyproxy, который был выбран как второй. Но тут я сосу, потому что в момент "-t mangle -A OUTPUT" все насчет маршрутизации все решено и set-mark бестолку.

Надо чтобы перероутилось, тогда делаю SNAT:

pluto ~ # iptables -t nat -A POSTROUTING -m mark --mark 1104 -j SNAT --to 192.168.0.55

tcpdump-ом вижу, что пакеты на нужный интерфейс и мак уходят, и ответы приходят, но только contrack похоже их не понимает и по прежнему ждет на eth0/1:

pluto ~ # tcpdump -i eth4 -n ether host 00:26:18:8C:B6:9F
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), capture size 96 bytes
00:47:27.472972 IP 192.168.0.55.39197 > 87.250.251.11.80: S 2086327592:2086327592(0) win 5840 <mss 1460,sackOK,timestamp 157071791 0,nop,wscale 7>
00:47:27.571850 IP 87.250.251.11.80 > 192.168.0.55.39197: S 1100594652:1100594652(0) ack 2086327593 win 65535 <mss 1360>
00:47:30.571437 IP 87.250.251.11.80 > 192.168.0.55.39197: S 1100594652:1100594652(0) ack 2086327593 win 65535 <mss 1360>
00:47:32.468944 arp who-has 192.168.0.251 tell 192.168.0.55
00:47:32.469182 arp reply 192.168.0.251 is-at 00:26:18:8c:b6:9f
00:47:36.571564 IP 87.250.251.11.80 > 192.168.0.55.39197: S 1100594652:1100594652(0) ack 2086327593 win 65535 <mss 1360>
00:47:37.191444 IP 87.250.251.11.80 > 192.168.0.55.39197: R 1:1(0) ack 1 win 5840
00:47:41.567531 arp who-has 192.168.0.55 tell 192.168.0.251
00:47:41.567542 arp reply 192.168.0.55 is-at 00:02:b3:e9:92:92
00:47:51.468981 IP 192.168.0.55.39197 > 87.250.251.11.80: S 2086327592:2086327592(0) win 5840 <mss 1460,sackOK,timestamp 157077791 0,nop,wscale 7>
00:47:51.572099 IP 87.250.251.11.80 > 192.168.0.55.39197: S 1925411223:1925411223(0) ack 2086327593 win 65535 <mss 1360>
00:47:54.571386 IP 87.250.251.11.80 > 192.168.0.55.39197: S 1925411223:1925411223(0) ack 2086327593 win 65535 <mss 1360>
00:26:18:8C:B6:9F - мак yota-роутера.

Как быть? Вообще NAT на хосте работает нормально, по крайней мере на eth0. Без хитрых правил tinyproxy тоже работает нормально, но естественно через eth0/eth1.


pluto ~ # iptables -t nat -A POSTROUTING -m mark --mark 1104 -j SNAT --to 192.168.0.55

опечатка, следует читать:

pluto ~ # iptables -t nat -A POSTROUTING -m mark --mark 1104 -j SNAT --to-source 192.168.0.55

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

У tinyproxy вроде была опция bind, пусть биндится на отдельный ip, его вы уже заворачивайте куда хотите через «ip rule src», а на выходе, если надо, делайте SNAT.

А относительно вашего dumpa, проверьте правила в iptables, может там всё режется.

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

С Bind-ом тоже пробовал. Даже делал второй адрес на eth4, но тогда на этот адрес и другие процессы покушаются - получается петрушка полная.

Решилось костылем: если установить rt_filter=0 для eth4, то все работает.

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

>Решилось костылем: если установить rt_filter=0 для eth4, то все работает.

Это не костыль, а true way. rp_filter обеспечивает _статическую_ фильтрацию, и абсолютно не совместим с полиси-роутингом.

P.S. Большой ман по теме нескольких линков есть в википедии, в статье про iptables (автор я, поэтому все багрепорты можно кидать в меня).

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