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

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

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

кроме 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, которые здесь регулярно находят.

Вообще изначальную задачу можно сформулировать очень просто:
необходимо к машине с ОС 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.

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

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

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

Нет. Обратный пакет автоматически обрабатывается в 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 отключить.

не едут лыжи

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

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

FORWARD разреши

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

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

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

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

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

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

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

main после local

ip ru add pref 10 lookup main

ip ru add pref 2000 lookup default

ip ru del pref 32766

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

Я минут 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

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