У меня есть сервер OpenVPN на маршрутизаторе MultiWAN (на основе Ubuntu). Проблема в том, что входящие пакеты не покидают тот же интерфейс WAN, куда они вошли. Я уже тестировал правила iptables MARK в сочетании с правилами ip, но не смог решить проблему. Я знаю, что могу определить конфигурацию openvpn с помощью local 79.1.2.3 исходящий ip, но я хочу, чтобы он был более гибким, если это возможно. Протокол порта OpenVPN - это UDP, если это важно.
$ ip r s|grep default
default via 83.1.2.3 dev vlan254 metric 1
default via 79.1.2.3 dev ppp0 metric 2
default via 192.168.0.251 dev vlan10 metric 3 onlink
$ ip rule s
0: from all lookup local
100: from all fwmark 0x1 lookup uplink1
101: from 83.1.2.3 lookup uplink1
102: from all to 83.1.2.3 lookup uplink1
200: from all fwmark 0x2 lookup uplink2
201: from 79.1.2.3 lookup uplink2
300: from all fwmark 0x3 lookup uplink3
301: from 192.168.0.254 lookup uplink3
302: from all to 192.168.0.254 lookup uplink3
32766: from all lookup main
32767: from all lookup default
# iptables -L -vn -t mangle
Chain PREROUTING (policy ACCEPT 4785K packets, 5178M bytes)
pkts bytes target prot opt in out source destination
4785K 5178M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
3985K 5035M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x0
351 46210 MARK all -- vlan254 * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1
3865 242K MARK all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 MARK set 0x2
351 46210 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x1 CONNMARK save
3865 242K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2 CONNMARK save
Chain INPUT (policy ACCEPT 1658K packets, 1114M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 3127K packets, 4063M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 1534K packets, 1241M bytes)
pkts bytes target prot opt in out source destination
1534K 1241M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
657K 103M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x0
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:55394 MARK set 0x2
0 0 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x1 CONNMARK save
0 0 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2 CONNMARK save
Chain POSTROUTING (policy ACCEPT 4639K packets, 5303M bytes)
pkts bytes target prot opt in out source destination
4639K 5303M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
3743K 4164M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x0
90 7560 MARK all -- * vlan254 0.0.0.0/0 0.0.0.0/0 MARK set 0x1
57161 3664K MARK all -- * ppp0 0.0.0.0/0 0.0.0.0/0 MARK set 0x2
896K 1140M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save
Таким образом, входящие пакеты поступают из восходящего канала 2, но оставляют восходящий канал 1 (gw по умолчанию).
Любая идея, как я могу решить свою проблему?
Посмотрим, смогу ли я объяснить это немного лучше:
Предположим, у вас есть хост где-то в Интернете, который отправляет пакет IP в вашу сеть. Допустим, он исходит от IP-адреса. 1.2.3.4.
Пакет прибывает в вашу сеть из любого vlan254 или ppp0 ссылка на сайт. Которая пересылается в пункт назначения в вашей сети (иначе через uplink3).
Теперь тот, кто получил посылку, должен ответить, поэтому он отправит посылку с адресом назначения. 1.2.3.4.
Поскольку оба uplink1 и uplink2 есть путь к 1.2.3.4 любой из них работает как допустимый путь, пакет затем будет перенаправлен через ссылку с наименьшей метрикой, которая uplink1.
Это в основном то, что происходит в 10.4.2. Inbound traffic Using Multiple Connections to the Internet по моей ссылке выше.
Однако вы хотели:
uplink1 тогда любой ответ выйдет через uplink1.uplink2 также будет дан ответ, используя uplink2.Это означает, что вы приземлились прямо в мире multihomed networking.
Я предполагаю, что вы использовали возможность маркировать посылку, чтобы отслеживать, откуда она пришла? Увы, маркировка используется только в том случае, если у вас есть IP-пакеты, которые необходимо маршрутизировать по разным путям, в зависимости от того, какой номер порта изначально использовался как порт источника или как порт назначения.
Альтернативное решение из моей ссылки состояло в том, чтобы позволить вашему серверу прослушивать 2 IP-адреса, а затем выполнять форму обратного NAT, когда весь входящий трафик перенаправляется на тот или иной IP-адрес в зависимости от того, какая ссылка была использована.
Затем вы можете перенаправить трафик через правильную ссылку в зависимости от исходного IP-адреса вашего сервера.
Вы также можете запустить OpenVPN на двух разных портах (например, 1194 и 1195) и использование маркировки для пересылки любых ответов по той или иной ссылке в Интернет.