MikroTik: пропадает трафик через WireGuard-клиента

WireGuard на MikroTik работает достаточно стабильно, но иногда трафик через VPN-клиента «пропадает»: туннель поднят, пиры видны, а пакеты не идут. Обычно это не проблема самого WireGuard, а ошибки в настройке маршрутизации, firewall или MTU. Разберём, как последовательно найти причину.

Проверьте базовое состояние WireGuard

Первым делом убедитесь, что туннель действительно поднят и через него идут пакеты. Выполните:

/interface wireguard print
/interface wireguard peers print

Обратите внимание на столбцы rx и tx. Если они не растут при попытке доступа к удалённой сети, значит проблема на уровне туннеля или маршрутизации. Также проверьте, что состояние пира — established, а не handshake.

Если счётчики растут, но до конечного узла трафик не доходит — переходите к следующему пункту.

MTU и MSS: настройте правильно, чтобы пакеты не терялись

WireGuard добавляет к каждому пакету заголовок в 32 байта (IPv4) или 48 байт (IPv6). Если MTU на туннельном интерфейсе оставить по умолчанию 1500, большие пакеты будут фрагментироваться или отбрасываться. Рекомендуется устанавливать MTU 1420 или меньше, в зависимости от вашего соединения. Проверьте текущее значение:

/interface wireguard print

Если MTU больше 1420 — измените его:

/interface wireguard set [find name=wg1] mtu=1420

Кроме того, настройте MSS clamping в файрволле, чтобы TCP-сессии не отправляли пакеты больше допустимого. Пример правила для forward-цепи (адаптируйте под свою схему):

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu passthrough=yes

Эту настройку важно проверить для обеих сторон туннеля.

Проверьте маршруты и NAT

Если туннель поднят и счётчики растут, но до удалённых адресов нет доступа, почти всегда виноваты маршруты. Убедитесь, что в таблице маршрутизации есть запись для сетей, которые должны быть доступны через WireGuard:

/ip route print

Для клиента обычно добавляется маршрут на удалённую подсеть с gateway-интерфейсом wg1. Также важно, чтобы ответные пакеты могли вернуться обратно — на серверной стороне должен быть разрешён форвардинг этой сети и настроен NAT (masquerade) для трафика из туннеля, если это нужно.

/ip firewall nat print

Если маршруты есть, но трафик всё равно не проходит, проверьте, не перекрывают ли другие маршруты ваш туннельный маршрут, и настройте более специфичные правила.

Firewall: не блокирует ли он нужный трафик

На MikroTik стандартное правило firewall может отбрасывать трафик из VPN. Проверьте правила forward и input:

/ip firewall filter print

Обычно нужно разрешать established, related и untracked, а также явно разрешать forward-трафик между туннелем и внутренней сетью. Если у вас есть правило drop-all в конце, убедитесь, что перед ним есть разрешающие правила.

Обратите внимание на цепочку input — если вы не разрешили доступ к самому интерфейсу wg1, то WireGuard может не получать handshake. Также проверьте, что порт WireGuard открыт на внешнем интерфейсе, если это сервер.

Keepalive, DNS и другие мелочи

Иногда трафик пропадает только после простоя. Включите persistent keepalive на пире, чтобы туннель не разрывался из-за NAT:

/interface wireguard peers set [find] persistent-keepalive=25s

Если пропадает только DNS, проверьте, какой DNS-сервер используется внутри туннеля. Возможно, вы забыли добавить маршрут для DNS или зарезолвить адрес сервера.

Также стоит проверить, не конфликтует ли адрес локальной сети с адресами внутри VPN, и не совпадают ли подсети. Если всё перечисленное не помогло, посмотрите логи на обеих сторонах туннеля и убедитесь, что версия RouterOS поддерживает WireGuard и не имеет известных ошибок — проверьте для вашей версии.