http://mikrotik.moscow Новое в теме BTH BUG просачивается в обычный Wireguard. форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Fri, 31 Jul 2026 18:49:52 -0400 BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
Правила маршрутизации не применимы, когда используются динамические IP-адреса. Сейчас я использую DNAT-правило, которое придумал Анав, и оно работает, но это точно баг.
12.05.2024 15:58:00, Cha0s.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393359 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393359 Sun, 12 May 2024 15:58:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
Хм, есть два варианта: можно использовать правило dst-nat или использовать маршрутные правила. Маршрутные правила, вроде, более понятные. Но в моём первом сообщении речь шла о MT, который выступает сервером для рукопожатия! Насчёт MT как клиента при рукопожатии не уверен, но если пытаться контролировать, какой WAN использовать — можно представить что-то похожее. Чтобы освежить воспоминания по dst-nat правилу:  
/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  
Когда хочешь принимать Wireguard трафик на WAN2, хотя WAN1 — основной. Мы, так сказать, «обманываем» роутер, чтобы он не менял назначение любого Wireguard-трафика, приходящего с WAN1, а отправлял его обратно через WAN2 при выходе.
12.05.2024 15:07:00, anav.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393358 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393358 Sun, 12 May 2024 15:07:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
У меня такая же проблема в точно такой же ситуации с двумя WAN и WireGuard на неосновном WAN.
12.05.2024 10:09:00, Cha0s.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393357 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393357 Sun, 12 May 2024 10:09:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
@anav, ты уже сообщил об этом баге? Похоже, что они могут и не исправить... Частично причина, почему WG такой быстрый, в том, что это происходит на уровне ядра, а вот переключение на mangle, скорее всего, скажется на производительности. Но я точно не знаю. В общем, это как раз обратная претензия к @DarkNate из его [Discussion] о сложности абстракции конфигурации MikroTik, где он выступает за большее использование datapaths на уровне ядра вместо правил mangle. «Гибкость» — не проблема, проблема в том, что для обработки данных используется фреймворк Linux Netfilter. (перевод: /ip/firewall/mangle == Linux Netfilter)
11.05.2024 16:07:00, Amm0.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393356 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393356 Sat, 11 May 2024 16:07:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
Итак, есть два варианта решения: правило dst-nat, указанное выше, или использование правил маршрутизации согласно Rplant. Пока MT не разберётся с этой неразберихой.
11.05.2024 13:34:00, anav.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393355 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393355 Sat, 11 May 2024 13:34:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
Ну, лучше использовать правила маршрутизации, а не mangle. Хотя mangle здесь тоже должен работать, чтобы быть совместимым с RouterOS… но WG, кажется, слишком строго следует тому, как это сделано в ядре Linux, а не в потоке пакетов Mikrotik.
12.05.2024 13:51:00, Amm0.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393354 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393354 Sun, 12 May 2024 13:51:00 -0400 RouterOS BTH BUG просачивается в обычный Wireguard. RouterOS в форуме RouterOS.
У меня обычная ситуация, когда 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…
06.04.2024 18:20:00, anav.]]> http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393353 http://mikrotik.moscow/forum/forum57/85116-bth-bug-prosachivaetsya-v-obychnyy-wireguard./message393353 Sat, 06 Apr 2024 18:20:00 -0400 RouterOS