У меня обычная ситуация, когда WIREGUARD должен работать через WAN2, несмотря на то, что WAN1 — основной маршрут. Пример: AX3 в роли пира (клиент для рукопожатия) и CCR2004 в роли пира (сервер для рукопожатия). Всё легко решается при помощи базового манглинга, таблиц и маршрутизации.
/ip mangle
add chain=input action=mark-connection connection-mark=no-mark in-interface=WAN2 new-connection-mark=incomingWAN2 passthrough=yes
add chain=output action=mark-route connection-mark=incomingWAN2 new-route-mark=useWAN2 passthrough=no
/routing-table
add fib name=useWAN2
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=gw1-IP check-gatway=ping
add distance=2 dst-address=0.0.0.0/0 gateway=gw2-IP check-gatway=ping
add dst-address=0.0.0.0/0 gateway=gw2-IP routing-table=useWAN2
Проблема в том, что хотя туннель вроде бы поднимается, он работает неправильно — доказательство в том, что не получается подключиться к роутеру через winbox. Довольно грубое решение, которое вроде сработало — добавить вот это правило Dstnat, которое, кстати, совершенно неочевидно:
/ip firewall nat
chain=dstnat dst-address-type=local in-interface=WAN2 protocol=udp dst-port=wg-port action=dst-nat to-addresses=ip.of.wan.1
До применения этого правила в трекинге соединений видно, что первый запрос от моего публичного IP идёт на WAN2, но ответ приходит с WAN1… очень странно. Оба такие соединения отмечены как C… (то есть без ответов?) После применения правила с WAN1 к моему wireguard-соединению ответов больше не было, прогресс есть. Трекинг соединений переключался (никогда одновременно) между Cd сейчас и SACd — они появлялись и исчезали…
Почему я думаю, что это какая-то ошибка BTH? Потому что на данном пира (сервере для рукопожатия) не стоит keep alive, а значит, почему модуль wireguard связывается и использует WAN1, несмотря на наш манглинг? Почему он активно пытается «достучаться» до wireguard-пира (клиента для рукопожатия)? Логичные объяснения:
а) persistent keep alive (не наш случай);
б) wireguard пытается отправить какой-то полезный трафик обратно пиру (возможно);
в) баг BTH, при котором сервер продолжает пытаться заново установить соединение с клиентом.
В случаях б) и в) wireguard пытается подключиться к последнему известному адресу/порту пира, то есть к публичному IP (моему) клиента, но использует для этого основной маршрут роутера — в нашем случае WAN1. Что касается BTH-трафика, это не ответ клиенту, а попытка обновить IP-параметры пира.
В итоге модуль wireguard игнорирует адрес назначения для рукопожатия и просто выходит через основной WAN, поскольку это исходящий трафик, а не ответный. Почему правило dst-nat работает — оно творит магию! Оно заставляет все ответы с локального интерфейса выглядеть так, будто это ответы на входящий трафик с удалённого пира, и им ставится connection-mark, после чего они маршрутизируются через WAN2.
++++++++++++++++++++++++++++++++++
Описание бага: даже если на обоих концах нет keepalive и полный простой до первого транспортного пакета, отправленного инициализирующим пиром, отвечающий пир шлёт ответ с адреса, выбранного маршрутизацией, а не с того, на который пришёл первый пакет.
++++++++++++++++++++++++++++++++++
Прошу других попытаться воспроизвести это странное, если не баговое, поведение. Хочу убедиться, что не с ума сошёл, прежде чем обращаться в MT…
/ip mangle
add chain=input action=mark-connection connection-mark=no-mark in-interface=WAN2 new-connection-mark=incomingWAN2 passthrough=yes
add chain=output action=mark-route connection-mark=incomingWAN2 new-route-mark=useWAN2 passthrough=no
/routing-table
add fib name=useWAN2
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=gw1-IP check-gatway=ping
add distance=2 dst-address=0.0.0.0/0 gateway=gw2-IP check-gatway=ping
add dst-address=0.0.0.0/0 gateway=gw2-IP routing-table=useWAN2
Проблема в том, что хотя туннель вроде бы поднимается, он работает неправильно — доказательство в том, что не получается подключиться к роутеру через winbox. Довольно грубое решение, которое вроде сработало — добавить вот это правило Dstnat, которое, кстати, совершенно неочевидно:
/ip firewall nat
chain=dstnat dst-address-type=local in-interface=WAN2 protocol=udp dst-port=wg-port action=dst-nat to-addresses=ip.of.wan.1
До применения этого правила в трекинге соединений видно, что первый запрос от моего публичного IP идёт на WAN2, но ответ приходит с WAN1… очень странно. Оба такие соединения отмечены как C… (то есть без ответов?) После применения правила с WAN1 к моему wireguard-соединению ответов больше не было, прогресс есть. Трекинг соединений переключался (никогда одновременно) между Cd сейчас и SACd — они появлялись и исчезали…
Почему я думаю, что это какая-то ошибка BTH? Потому что на данном пира (сервере для рукопожатия) не стоит keep alive, а значит, почему модуль wireguard связывается и использует WAN1, несмотря на наш манглинг? Почему он активно пытается «достучаться» до wireguard-пира (клиента для рукопожатия)? Логичные объяснения:
а) persistent keep alive (не наш случай);
б) wireguard пытается отправить какой-то полезный трафик обратно пиру (возможно);
в) баг BTH, при котором сервер продолжает пытаться заново установить соединение с клиентом.
В случаях б) и в) wireguard пытается подключиться к последнему известному адресу/порту пира, то есть к публичному IP (моему) клиента, но использует для этого основной маршрут роутера — в нашем случае WAN1. Что касается BTH-трафика, это не ответ клиенту, а попытка обновить IP-параметры пира.
В итоге модуль wireguard игнорирует адрес назначения для рукопожатия и просто выходит через основной WAN, поскольку это исходящий трафик, а не ответный. Почему правило dst-nat работает — оно творит магию! Оно заставляет все ответы с локального интерфейса выглядеть так, будто это ответы на входящий трафик с удалённого пира, и им ставится connection-mark, после чего они маршрутизируются через WAN2.
++++++++++++++++++++++++++++++++++
Описание бага: даже если на обоих концах нет keepalive и полный простой до первого транспортного пакета, отправленного инициализирующим пиром, отвечающий пир шлёт ответ с адреса, выбранного маршрутизацией, а не с того, на который пришёл первый пакет.
++++++++++++++++++++++++++++++++++
Прошу других попытаться воспроизвести это странное, если не баговое, поведение. Хочу убедиться, что не с ума сошёл, прежде чем обращаться в MT…
