Несколько маршрутов по умолчанию

0

2

Добрый день. Тут производственная задача - проверять время от времени, живой ли у нас резервный канал, пытаюсь вот сделать, и что-то не получается - подскажите, пожалуйста, в чём тут проблема.

Конфигурация:

2 openvpn-сети: 10.17.17.0/24 и 10.17.30.0/24, по умолчанию траффик идёт через 10.17.30.1, резервный шлюз, соответственно - 10.17.17.20.

Как я собираюсь решить задачу:iptables транслирует, например, 888-й порт в 80-й и ставить метку, а с помощью iproute2 по этой метке юзать отдельную таблицу с дефолтным маршрутом через 10.17.17.20. Конфигурация:

ip route show

default via 10.17.30.1 dev tap0 
10.17.17.0/24 dev tap1  proto kernel  scope link  src 10.17.17.10 
10.17.18.0/24 via 10.17.17.1 dev tap1 
10.17.30.0/24 dev tap0  proto kernel  scope link  src 10.17.30.3

ip rule show

0:      from all lookup local 
32765:  from all fwmark 0x2 lookup rt_vpn 
32766:  from all lookup main 
32767:  from all lookup default

ip route show table rt_vpn
default via 10.17.17.20 dev tap1 
10.17.17.0/24 dev tap1  scope link  src 10.17.17.10

iptables -t nat -S

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A OUTPUT -p tcp -m tcp --dport 888 -j MARK --set-xmark 0x2/0xffffffff
-A OUTPUT -p tcp -m tcp --dport 888 -j DNAT --to-destination :80

Коннект проверяется с помощью «nc -z 93.158.134.11 888 ». Глухо. tcpdump на 10.17.17.20 почему-то показывает, что пакеты идут с адреса 10.17.30.3 - мистика!

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:13:37.389236 IP (tos 0x0, ttl 64, id 15685, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xdde0 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946229544 ecr 0,nop,wscale 7], length 0
11:13:37.389254 IP (tos 0x0, ttl 63, id 15685, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xdde0 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946229544 ecr 0,nop,wscale 7], length 0
11:13:38.390532 IP (tos 0x0, ttl 64, id 15686, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xd9f6 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946230546 ecr 0,nop,wscale 7], length 0
11:13:38.390542 IP (tos 0x0, ttl 63, id 15686, offset 0, flags [DF], proto TCP (6), length 60)
    10.17.30.3.33030 > 93.158.134.11.80: Flags [S], cksum 0xd9f6 (correct), seq 1971022957, win 29200, options [mss 1336,sackOK,TS val 946230546 ecr 0,nop,wscale 7], length 0

А, и правила на 10.17.17.20:

iptables -t nat -S

-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A POSTROUTING -s 10.17.16.0/22 -o eth0 -j SNAT --to-source <внешний_ip>

Ссылка

←	OpenVPN создать сного пользователей (автоматизация)

Equal Cost балансировка в Linux

→

Очевидно, что проблема в src IP исходящих пакетов. Из-за него трафик не идёт т.к. 10.17.17.20:

скорее всего не имеет [обратного] маршрута до сети 10.17.30.0/24
не делает SNAT для пакетов от 10.17.30.3 (адрес не подпадает под 10.17.16.0/22)

Вопрос в том как повлиять на выбор src IP. Наверняка я не знаю, но моя теория такова: исходя из правил по адресу http://linux-ip.net/html/routing-saddr-selection.html ядро выбирает src IP согласно таблицам маршрутизации, но на этот момент netfilter ещё не участвует в процессе и поэтому правило с fwmark не срабатывает и выбирается адрес 10.17.30.3. Потом пакет проходит через netfilter, ему делается DNAT и навешивается mark. Далее опять происходит роутинг (согласно https://www.frozentux.net/iptables-tutorial/chunkyhtml/c962.html#TABLE.SOURCE...) и на этом шаге выбирается уже правильный маршрут, но src IP уже не меняется.

Отсюда напрашивается вывод, что использование fwmark для локального трафика не очень-то удобно.

Из простого я бы сначала попробовал просто явно сбиндиться на нужный адрес.