LINUX.ORG.RU

iptables: не едут лыжи

 , , ,


0

1

Уже мозг сломал.
Есть машина А (192.168.1.46, 192.168.10.220, 10.0.0.1) - шлюз,
и есть машиа Б (10.0.0.2, 10.0.0.3) (у нее в качестве основного шлюза стоит А - 10.0.0.1)
все что приходит на 192.168.1.46 (А) --> отправляем на машину Б

iptables -v -t nat -A PREROUTING  -d 192.168.1.46 -j DNAT --to 10.0.0.2
iptables -v -t nat -A POSTROUTING -s 10.0.0.2 -j SNAT --to 192.168.1.46
ну и раз это шлюз, то
iptables -v -t nat -A POSTROUTING -s 10.0.0.2 -o eth0 -j MASQUERADE
все без проблем работает как и ожидалось.


Так же на машину А (шлюз) приходит трафик GRE
tun0      Link encap:UNSPEC  HWaddr C0-A8-01-2E-30-30-3A-30-00-00-00-00-00-00-00-00
          inet addr:192.168.10.220  P-t-P:192.168.4.1  Mask:255.255.255.255
Сам по себе туннель работает, по нему можно подключиться к машине А.
далее tcpdump c машины А когда ее пингуешь по GRE
root@gw:~# tcpdump -p -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
12:26:50.306674 IP 192.168.1.100 > 192.168.10.220: ICMP echo request, id 1, seq 2222, length 40
12:26:50.306709 IP 192.168.10.220 > 192.168.1.100: ICMP echo reply, id 1, seq 2222, length 40

Но мне надо этот трафик тоже завернуть на машину Б:
iptables -v -t nat -A PREROUTING   -d 192.168.10.220 -j DNAT --to 10.0.0.3
iptables -v -t nat -A POSTROUTING  -s 10.0.0.3       -j SNAT --to 192.168.10.220
но пакеты они куда-то подевались,
192.168.10.220 на пинг уже не отвечает, а пакеты словно в черную дыру ушли.


туннель это в первую очередь маршрутизация, а не НАТ, которым ты пытаешься решить все проблемы.

туннель обычно используется чтоб можно было обмениваться данными без НАТа, что не работает без настройки маршрутизации с обеих сторон. Товарищи по ту сторону туннеля знают про все твои сети/адреса?

кроме ping-а есть еще traceroute и «ip ro get»

Если все совсем плохо, то есть «iptables -t raw ...-j TRACE»

и есть машиа Б (10.0.0.2, 10.0.0.3)

Как это настроено и зачем? 2 ip из одной сети это всегда источник граблей.

все что приходит на 192.168.1.46 (А) --> отправляем на машину Б

Если речь о входящих соединениях, то будет достаточно только правила в PREROUTING.

Если обнаружится ситуация когда входящие пакеты приходят через туннель, а ответ уходи в DGW (т.е. мимо туннеля), то мы столкнемся с необходимостью настроить policy-routing да еще в связке с conntrack.

В таких хитрых конструкциях нужно не забыть о граблях в виде rp_filter, которые здесь регулярно находят.

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

Вообще изначальную задачу можно сформулировать очень просто:
необходимо к машине с ОС Windows подключать неопределенное количество GRE/IPIP туннелей, которые предоставляются сервисами по фильтрации трафика (Stormwall, x4b, pro-managed и т.п.)
Проблема в том, что в Windows с туннелями все очень плохо, поэтому все делают так: ставят отдельную машину, которая используется как шлюз и к ней уже подключают GRE/IPIP туннели.

Подключить туннель к Linux с «телепортацией» адреса туннеля, никаких сложностей не вызывает, вот пример реализации https://debian.pro/1578 от которого я отталкивался
А как этот трафик еще завернуть на Windows машину не знаю.

Как это настроено и зачем? 2 ip из одной сети это всегда источник граблей.

Изначально есть машина, которая стоит за NATом, у нее адрес 10.0.0.2, весь трафик приходящий на машину шлюз я отправляю на этот адрес.
Вторая адрес для разделения трафика с туннеля. Отправляем трафик из туннеля на 10.0.0.3, если пришел ответ с 10.0.0.3 то «передаем» в туннель. Первая часть схемы работает, а вот вторая нет.

Если речь о входящих соединениях, то будет достаточно только правила в PREROUTING.

Подразумевается, что обратный адрес маскарадом будет подменяться?

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

суть всей пляски еще в том, что нужно сохранить оригинальные адреса клиентов, которые пришли хоть напрямую, хоть через GRE/IPIP туннели.

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

Подразумевается, что обратный адрес маскарадом будет подменяться?

Нет. Обратный пакет автоматически обрабатывается в conntrack, доп. правила NAT не требуется.

Если посмотреть на счетчики в таблице nat, то видно, что туда попадает только первый пакет соединения.

маскарад в данном случае нужен только для исходящих соединений.

А для работы через несколько туннелей - настраивай policy-routing.

Идея проста как грабли:

Первый пакет соединения пришедший через туннель должен маркировать conntrack (-j CONNMARK). Для ответных пакетов марка должна восстанавливаться из conntrack (-j CONNMARK --restore-mark) и по ней маршрутизировать.

настоятельно рекомендую:

1) вынести DGW из main в default.

2) После таблицы local должна просматриваться талица main, а уже после этого просматриваться таблицы с DGW для каждого туннеля.

ip ru add pref 100 lookup main
ip ru add pref 200 fwmark 1 lookup 101
ip ru add pref 201 fwmark 2 lookup 102
ip ru add pref 202 fwmark 3 lookup 103
...

3) rp_filter отключить.

vel ★★★★★ ()

не едут лыжи

Летом можно и на велосипеде...

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

Огромное спасибо, Ваш вариант мне нравится куда больше, чем мой велосипед, который, видимо, не работал из-за rp_filter

Hett ()

FORWARD разреши

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

Если бы форвард не был включен, то и он не смог бы как шлюз работать. А как шлюз он работает. Думаю проблема в rp_filter, я не знал про него. Сегодня вечером попробую свой вариант с выключенным фильтром. А потом переделаю на CONNMARK и routing-policy

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

мой велосипед заработал после выключения rp фильтра >_<

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

Даже с первого раза заработало. Честно, даже удивился.
Вот что получилось:

iptables -F
iptables -v -t nat -F
iptables -v -t mangle -F

#GRE 1
iptables -v -t mangle -A PREROUTING -d 192.168.10.220 -j CONNMARK --set-mark 1
iptables -v -t nat    -A PREROUTING -j DNAT --to 10.0.0.2

#COMMON
iptables -v -t mangle -A PREROUTING  -s 10.0.0.2     -j CONNMARK --restore-mark
iptables -v -t nat    -A PREROUTING  -d 192.168.1.46 -j DNAT --to 10.0.0.2
iptables -v -t nat    -A POSTROUTING -s 10.0.0.2 -o eth0 -j MASQUERADE

10.0.0.2 - машина с Windows

root@gw:~# ip rule show
0:      from all lookup local
1000:   from 192.168.10.220 lookup 200
1100:   from all fwmark 0x1 lookup 200
32766:  from all lookup main
32767:  from all lookup default

root@gw:~# ip route show table 200
default via 192.168.4.1 dev tun0  src 192.168.10.220  mtu 1350 advmss 1310


Правда пока не сообразил, как правильно перенести шлюз в таблицу default и как main выше поднять.

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

Наверное так будет правильнее?

iptables -v -t mangle -A PREROUTING -i tun0 -m state --state NEW -j CONNMARK --set-mark 1
iptables -v -t nat    -A PREROUTING -i tun0 -j DNAT --to 10.0.0.2

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

main после local

ip ru add pref 10 lookup main
и далее
ip ru add pref 2000 lookup default
или
ip ru del pref 32766

про шлюз - не устанавливай его штатными способами, а тупо добавь его скриптом в таблицу default.

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

Я минут 5 пытался найти как правилу поменять pref, а оказалось все просто.

auto eth0
iface eth0 inet static
    address 192.168.1.46
    netmask 255.255.255.0
    post-up /sbin/ip rule  add pref 10 lookup main
    post-up /sbin/ip route add default via 192.168.1.1 dev eth0 table default
    post-up /sbin/ip rule del pref 32766

А у нее гарантированно всегда будет изначальный pref 32766 ?

И, правда, не понял, для чего
32767:  from all lookup default


Она все равно в конце ведь
0:      from all lookup local
10:     from all lookup main
1000:   from 192.168.10.220 lookup 200
1100:   from all fwmark 0x1 lookup 200
32767:  from all lookup default

root@gw:~# ip route  show table main
10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.46
192.168.4.1 dev tun0  proto kernel  scope link  src 192.168.10.220

root@gw:~# ip route  show table default
default via 192.168.1.1 dev eth0

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