LINUX.ORG.RU
Форум — Admin  

Wireguard + Multiwan

 , , ,


0

2

Собственно есть сервер, на котором стоит wireguard. Есть 3 аплинка. В таблице маршрутизации следующее:

default
        nexthop dev eth1 weight 1
        nexthop dev eth2 weight 1
        nexthop dev ppp0 weight 1


и есть несколько клиентов. И тут возникает проблема при подключении «клиентов» к «серверу». Если условный клиент1 подключается к «серверу» через интерфейс eth1, то ответ на рукопожатие может уйти через eth2 или ppp0. И наоборот. То есть wireguard случайным образом выбирает интерфейс для ответа на рукопожатие. Канал в итоге не поднимается. Маркировка и добавление правил в таблицу маршрутизации в зависимости от метки не работают. Не работают именно с wireguard, с другими сервисами нет проблем. У того же openvpn есть схожая проблема, которая решается добавлением параметра multihomed. Тут подобного нет. Нашел на гитхабе issue в openwrt с такой же проблемой, но там обсуждение заглохло с прошлого года. Неужели нельзя заставить работать wireguard корректно и отправлять ответный пакет на хендшейк с того же интерфейса? Только начал переводить клиентов с опенвпн на wireguard, и тут такой облом.

Есть запасной вариант с использованием namespace/docker-wireguard. При такой схеме проблем нет. Оно и понятно, там wireguard не видит сами шлюзы хоста, а через шлюз контейнера отправляет. Но он мне не подходит, так как без нат сложно все там настроить. Мне не только клиенты на видеть, но и сети за ними. Тоже самое с клиентами, они должны видеть сеть на «сервером». И сильно хочу избежать использование NAT.

★★

Последнее исправление: as_lan (всего исправлений: 1)
← Не пингуется сервер на VM
Оцените безопасность iptables конфига →

отключайте у WG его «умную» маркировку, которая обычно только для десктопа работает. И маркируйте вручную.

И это, ip ro в студию.
И попробуйте ваш баг воспроизвести в том же virtualbox с несколькими NIC и несколькими default gw.

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666 
default
        nexthop dev eth1 weight 1
        nexthop via 10.134.31.1  dev eth2 weight 1
        nexthop dev ppp0 weight 1
10.89.89.0/24 dev wg0  proto kernel  scope link  src 10.89.89.1
10.134.31.0/24 dev eth2  proto kernel  scope link  src 10.134.31.21
100.100.100.100 dev ppp0 proto kernel  scope link  src xxx.xxx.xxx.xxx
172.20.0.0/20 dev eth0.10  proto kernel  scope link  src 172.20.0.1
172.20.16.0/24 dev eth0.20  proto kernel  scope link  src 172.20.16.1
176.120.208.0/22 dev eth1  proto kernel  scope link  src yyy.yyy.yyy.yyy
192.168.5.0/24 dev eth0.15  proto kernel  scope link  src 192.168.5.1
192.168.25.0/24 dev eth0.25  proto kernel  scope link  src 192.168.25.1
192.168.30.0/24 dev eth0.30  proto kernel  scope link  src 192.168.30.1
192.168.35.0/24 dev eth0.35  proto kernel  scope link  src 192.168.35.1
192.168.40.0/21 dev eth0.40  proto kernel  scope link  src 192.168.40.2
192.168.135.0/24 dev tun0  proto kernel  scope link  src 192.168.135.1
192.168.140.0/24 dev tun1  proto kernel  scope link  src 192.168.140.1
192.168.150.0/24 dev tun2  proto kernel  scope link  src 192.168.150.1



А разве маркировка по умолчанию включена? Я знаю, что ее можно включить.

as_lan ★★
() автор топика
Последнее исправление: as_lan (всего исправлений: 1)

Помогло неотслеживание соединений через -j NOTRACK. По крайней мере с добавлением этого правила хендшейк уходит с того же интерфейса.

as_lan ★★
() автор топика
3 июня 2021 г.
Ответ на: комментарий от as_lan

И все таки не работает. Причем не работает рукопожатие, если я пытаюсь подключиться к pppoe интерфейсу. Обратный пакет уходит через eth1 или eth2. Если добавить правило типа

ip route add to xxx.xxx.xxx.xxx via ppp0

где xxx.xxx.xxx.xxx клиентский адрес, то все нормально конектится.

Пробовал маркировать входящие пакеты (NOTRACK отключил)

iptables -t mangle -N WG
iptables -t mangle -I PREROUTING -s XXX.XXX.XXX.XXX -p udp --dport 7880 -j WG
iptables -t mangle -A WG -j MARK --set-mark 0x3
iptables -t mangle -A WG -j CONNMARK --save-mark
iptables -t mangle -A WG -j ACCEPT
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark


Тоже не помогает. Если смотреть через conntrack -d xxx.xxx.xxx.xxx -L, то там на исходящем пакете нет маркировки, и в качестве src стоит адрес eth1/eth2 интерфейса.

Пробовал добавить в sysctl
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0

Не помогло.

Как победить?

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

Не знаю... Точно зрение проверять пора. Или хотя бы пыль с моника протереть :(

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

Кратко так. Не должно быть шлюза по умолчанию в таблице main. Добавляете их в отдельные таблицы t1, t2, t3. При получении NEW (в терминах iptables) пакета маркируете соединение (CONNMARK) в зависимости от того на какой интерфейс прилетело. Например eth1 - 0x10, eth2 - 0x20, ppp0 - 0x30.
iptables -t mangle -A PREROUTING -i eth1 -m state --state NEW -j CONNMARK --set-mark 0x10
....
Добавляете правила
ip rule add fwmark 0x10 table t1
....
после них добавить правила
ip rule add from $ip_eth1 table t1
ip rule add from $ip_eth2 table t2
ip rule add from $ip_ppp0 table t3

iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
Вроде ничего не забыл.

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

Если нет шлюза в таблице main, то куда уходят пакеты, которые генерируется локальными процессами? Сейчас у меня такая же схема, которую вы описали, но шлюз есть в main и выглядит 

default
        nexthop dev eth1 weight 1
        nexthop via 10.134.31.1  dev eth2 weight 1
        nexthop dev ppp0 weight 1

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

Если нет шлюза в таблице main, то куда уходят пакеты, которые генерируется локальными процессами?

Отправляются согласно правилам ip rule. К слову так же как и в таблицу main. Говоря по другому, сами по себе таблицы это не более чем таблицы, а вот пакетики в них направляют правила. Наберите ip rule show и ip route show table all думаю что станет понятнее.
Да, правила исполняются согласно priority от меньшего к большему, это первая цифирка в выхлопе ip ru s

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Не пингуется сервер на VM
Admin
Оцените безопасность iptables конфига →