Ситуация выглядит почти обидно: туннель поднялся, handshake есть, пакеты вроде бы ходят, а сайты не открываются и мессенджеры молчат. На MikroTik это особенно сбивает с толку, потому что сам факт успешного обмена ключами создает ощущение, что все уже настроено правильно. На деле handshake в WireGuard говорит только об одном: устройства видят друг друга и могут обменяться служебными пакетами. До маршрутизации, NAT и фильтрации трафика он еще не дотягивается.

Именно поэтому проблема часто прячется не в самом WireGuard, а в соседних настройках. Где-то не хватает маршрута, где-то забыли masquerade, где-то неверно указан Allowed Address, а иногда трафик уходит в туннель и упирается в правила firewall. Ниже разберем те места, где чаще всего теряется связь, и покажем, как шаг за шагом вернуть интернет через туннель на MikroTik.

Почему handshake не гарантирует рабочий интернет

Handshake подтверждает только то, что между пирами есть базовая связность и совпали криптографические параметры. Это важный этап, но сам по себе он не дает ни маршрута, ни выхода в интернет. Если после поднятия туннеля трафик не идет, значит, проблема уже находится на уровне маршрутизации, адресации или трансляции адресов.

В WireGuard нет магии, которая автоматически разрулит весь путь пакета. Устройство должно знать, какой трафик отправлять в туннель, как его принимать обратно и как выпускать его наружу. На MikroTik к этому добавляется еще и привычная для RouterOS история с таблицами маршрутизации, firewall и отдельной логикой обработки интерфейсов.

Если смотреть на задачу практично, handshake можно воспринимать как светящийся индикатор на панели. Он полезен, но не показывает, заведется ли машина в дороге. Поэтому начинать проверку лучше не с повторной генерации ключей, а с маршрута пакета от клиента до внешнего адреса и обратно.

«Handshake в WireGuard доказывает только одно: канал для управления жив. Доступ в сеть зависит уже от того, как настроены маршруты и NAT».

«Если туннель поднят, а трафик не идет, почти всегда стоит искать не в шифровании, а в том, что происходит после него».

Первое, что стоит проверить: адреса и Allowed Address

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

Особое внимание стоит уделить полю Allowed Address. В WireGuard оно одновременно влияет и на допустимые источники, и на то, какой трафик будет отправляться через пир. Если на клиенте в Allowed Address прописана только адресация самого туннеля, а не нужный маршрут, внешний трафик просто не попадет в него. Если же указан слишком широкий диапазон, можно случайно увести в туннель лишние сети и запутать маршрутизацию.

На MikroTik полезно сверить адреса интерфейса WireGuard, IP на пире и реальные подсети LAN. Типичный случай из практики выглядит так: туннель использует 10.10.10.0/24, локальная сеть тоже сидит на 10.10.10.0/24 или рядом с ней, и роутер начинает выбирать не тот путь. Формально все живо, а по факту пакет блуждает по неправильной ветке.

Что проверить	Что должно быть в порядке
IP-адрес WireGuard-интерфейса	Отдельная подсеть, не пересекающаяся с LAN
Allowed Address на клиенте	Сети, которые действительно должны идти через туннель
Allowed Address на MikroTik	Адрес клиента или подсеть, если через него идет сеть
Локальные сети	Не должны конфликтовать с туннельными адресами

Маршрутизация: трафик должен понимать, куда ему идти

Даже при правильных адресах интернет не появится, если роутер не знает, через какой интерфейс отправлять пакеты. Для full tunnel на клиенте нужен маршрут по умолчанию через WireGuard, а на MikroTik должен быть понятный путь в сторону провайдера. Если используется split tunnel, то в маршрутах должны быть перечислены только нужные сети, иначе часть трафика останется снаружи.

На стороне MikroTik стоит посмотреть таблицу маршрутов и убедиться, что она не конфликтует с существующими правилами. Иногда пользователь добавляет статический маршрут, а потом забывает про policy routing, который перехватывает тот же трафик в другую таблицу. В результате handshake идет, входящие пакеты приходят, а исходящие уходят не туда.

Если через туннель должен ходить весь интернет, у клиента обычно должен появиться маршрут 0.0.0.0/0 через WireGuard. На роутере при этом важно, чтобы сам пир не оказался отрезанным от своей стороны интернета. Это отдельный и довольно частый сценарий, когда после включения туннеля исчезает доступ даже к удаленному MikroTik, потому что маршрут к его публичному адресу оказался завернут внутрь туннеля.

Когда помогает обычная проверка маршрута

В MikroTik проще всего посмотреть активные маршруты и понять, куда пойдет пакет до конкретного адреса. Если есть сомнения, полезно проверить маршрут до внешнего DNS или до IP клиента. Это быстро показывает, не съехал ли трафик в неожиданную таблицу.

В рабочих сетях я не раз видел одно и то же: настройки выглядят аккуратно, интерфейс зеленый, handshake обновляется, а весь интернет ломает один забытый маршрут по умолчанию. Особенно часто это случается после ручной правки конфигурации, когда старые правила остаются в системе и начинают спорить между собой.

NAT и masquerade: без них выход в интернет часто обрывается

Если через туннель уходит частная адресация, удаленная сторона должна уметь преобразовать ее в свой внешний адрес. На MikroTik для этого обычно используют srcnat с masquerade или явным src-nat. Без этой трансляции удаленные сайты видят пакет с приватным адресом и просто не знают, куда отвечать.

Это одна из самых частых причин, почему handshake есть, а интернета нет. Туннель работает, ответы от пира приходят, но дальше пакет упирается в отсутствие NAT. Особенно заметно это при выходе клиентов в интернет через MikroTik, когда весь исходящий трафик должен маскироваться под публичный адрес роутера.

Важно смотреть не только само правило masquerade, но и его место в цепочке NAT. Если выше стоит более специфичное правило, пакет может пройти мимо маскарадинга. Иногда проблема оказывается совсем в другом интерфейсе: правило написано для ether1, а реальный выход в интернет идет через PPPoE или LTE, и трансляция не срабатывает.

«Если трафик из туннеля выходит с частным адресом в сторону интернета, внешняя сеть не обязана понимать вашу внутреннюю топологию».

Проверять NAT лучше в связке с реальным путем пакета. На MikroTik удобно смотреть счетчики правил. Если счетчик на masquerade стоит на месте, значит, пакеты до него не доходят. Тогда проблема не в NAT, а раньше по цепочке: в маршруте, firewall или выборе интерфейса.

Firewall: трафик может доходить до роутера и исчезать внутри него

Firewall на MikroTik легко превращает рабочую схему в загадку, потому что handshake проходит через отдельную логику, а полезный трафик уже попадает под обычные правила фильтрации. Если входящий трафик с WireGuard-интерфейса не разрешен, пинги и DNS могут просто отбрасываться. То же касается forwarding между туннелем и LAN, а также доступа в интернет через роутер.

Самая частая ошибка здесь звучит просто: разрешили сам WireGuard, но забыли разрешить forward. В результате служебные пакеты ходят, интерфейс живой, а данные, которые должны идти сквозь роутер, режутся фильтром. Иногда достаточно одного жесткого drop в конце списка, чтобы весь туннель выглядел исправным только наполовину.

На практике полезно проверить, есть ли явные accept-правила для трафика из интерфейса WireGuard в сторону LAN и WAN. Если у вас жесткая политика firewall, ее нужно дополнять адресно. Иначе роутер будет вежливо подтверждать handshake и так же вежливо блокировать все остальное.

Где обычно прячется проблема

• нет accept для input с WireGuard-интерфейса;

• нет accept для forward между WireGuard и LAN;

• drop стоит выше разрешающего правила;

• в правилах используется не тот интерфейс или не та подсеть;

• включен fasttrack, который мешает диагностике отдельных потоков.

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

DNS: интернет вроде есть, а открываться ничего не хочет

Иногда с туннелем все в порядке, но кажется, что интернета нет. На деле пакеты до внешних адресов проходят, просто не работает DNS. Тогда ping по IP может идти, а сайты по именам не открываются. Этот сценарий часто принимают за поломку WireGuard, хотя проблема лежит на уровне резолвера.

Если клиент получает DNS от MikroTik или от удаленной сети, нужно проверить, доступен ли он через туннель и разрешен ли в firewall. Нередко DNS-сервер прописан вручную, но в Allowed Address его подсеть не включена. В итоге устройство честно пытается спросить имя, но запрос не доходит.

Для проверки достаточно сравнить поведение по IP и по доменному имени. Если IP работает, а имена нет, искать надо в DNS-настройках, а не в самом туннеле. Это экономит время и убирает лишние предположения.

Как быстро разложить проблему по шагам

Когда картина размыта, полезно идти от простого к сложному. Сначала убедиться, что handshake обновляется, потом проверить адреса интерфейсов, затем маршруты и только после этого смотреть NAT и firewall. Такой порядок обычно быстрее, чем хаотичные попытки править все сразу.

Если используется доступ в интернет через удаленный MikroTik, проверьте еще и обратный путь. Пакет может уйти в туннель, выйти в интернет, а ответ вернется уже другим маршрутом. Для двусторонней связи важна симметрия, и именно она чаще всего ломается при ручной настройке.

Мне не раз попадались случаи, когда достаточно было исправить одну строчку в Allowed Address или добавить одно правило masquerade. Но увидеть это можно только тогда, когда проверка идет по цепочке, а не по ощущению. В таких задачах ощущение почти всегда обманывает.

Практический порядок проверки

1. Убедиться, что handshake свежий и обновляется.

2. Проверить адреса WireGuard-интерфейса и отсутствие пересечений.

3. Посмотреть маршруты на MikroTik и на клиенте.

4. Проверить NAT для трафика из туннеля.

5. Сверить firewall input и forward.

6. Отдельно проверить DNS, если IP-адреса открываются.

Если все перечисленное в порядке, а доступ все равно не появляется, тогда стоит смотреть логи, счетчики правил и реальный путь пакета с помощью инструментов диагностики RouterOS. Но в большинстве домашних и небольших офисных схем проблема находится раньше, на одном из базовых уровней. И именно там ее проще всего поймать.

WireGuard на MikroTik умеет создавать очень стабильный туннель, но сам по себе он не решает задачу выхода в сеть. Handshake показывает только то, что стороны договорились друг с другом. Чтобы трафик пошел дальше, должны совпасть маршруты, NAT, firewall и DNS. Когда эти части собраны аккуратно, туннель начинает работать предсказуемо, без странных провалов и исчезающих сайтов.