WireGuard подключён, а сервер недоступен: проверяем путь пакета
Почему handshake не гарантирует доступ к серверу. По порядку проверяем маршруты, input и forward, NAT, обратный путь и DNS.
- КлиентШлюз, адрес назначения и нужный сервис
- МаршрутизаторыТаблицы маршрутов, forward и трансляция
- СерверПриём соединения и маршрут ответа
Время последнего handshake обновляется, счётчик передачи растёт, но общая папка в другом офисе не открывается. Добавлять разрешающие правила наугад в этот момент особенно неудобно: скоро непонятно, какое из них помогло и что ещё оно открыло. Лучше выбрать один запрос и проследить его путь до сервера и обратно.
Берём одну понятную проверку
Пусть учебный клиент 10.60.10.25 обращается к серверу 10.60.20.40. Запишите протокол, порт и время попытки. Проверяйте именно этот сервис: отказ ping может означать лишь запрет ICMP на сервере. Сначала используйте IP-адрес, чтобы не смешивать сетевую недоступность с ошибкой имени.
# RouterOS: просмотр без изменения конфигурации
/ip/route/print detail where dst-address=10.60.20.0/24
/ip/firewall/filter/print stats where chain=forward
/ip/firewall/nat/print statsНа клиенте проверьте шлюз. На первом маршрутизаторе — активный маршрут к удалённой LAN, нужную таблицу и соответствующий peer. Если используются policy routing или дополнительные таблицы, наличие маршрута в main само по себе ничего не доказывает. Проверку полезно повторить с обычного рабочего компьютера: пакет, созданный роутером, идёт иначе и может иметь другой исходный адрес.
Не путаем доступ к роутеру с транзитом
Цепочка input относится к самому маршрутизатору. Соединение клиента с сервером за соседним роутером проходит через forward. Поэтому разрешённый входящий UDP-порт VPN не даёт автоматически доступа ко всем офисным ресурсам. Сверьте условия правил и их порядок: счётчик нужного разрешения должен расти на контрольной попытке, а запрет не должен перехватывать пакет раньше.
Разрешение лучше описывать конкретными сетями и сервисами. Не добавляйте весь VPN-интерфейс в доверенную LAN только ради проверки. На стороне сервера отдельно проверьте локальный firewall: он может принимать соединения из своей подсети, но отвергать соседний офис.
Ответу тоже нужен маршрут
Запрос дошёл до сервера — теперь смотрим, куда сервер отправляет ответ. Если его шлюз не знает сеть клиента, ответ уйдёт в другую сторону. Маскарадинг иногда скрывает эту ошибку, подменяя адрес клиента, но одновременно ухудшает видимость источников в журналах. Для обычного обмена между непересекающимися офисными LAN сначала исправляют маршрутизацию, затем отдельно решают, нужен ли NAT.
Сравните адрес источника до и после прохождения роутера. После изменения NAT проверяйте новое соединение: решение о трансляции запоминается в connection tracking. Не очищайте всю таблицу соединений на рабочем маршрутизаторе ради одной попытки.
По IP работает — проверяем имя
Уточните, какой DNS действительно использует клиент и какой адрес возвращается для сервиса. Старая запись или публичный ответ могут уводить запрос в обход VPN. Если DNS обслуживает сам RouterOS, доступ к нему тоже должен быть ограничен нужными сетями. Проверка считается законченной, когда работает исходная операция пользователя, а временные диагностические разрешения убраны.