VPN на FRITZ!Box подключается, но никто не отвечает: WireGuard или IPSec
Подключённый туннель FRITZ!Box, который не доходит до LAN, — это проблема адресации. Проверьте четыре поля IPSec или peer WireGuard перед повторным импортом.
Туннель сообщает, что подключён, значок зелёный, а в домашней LAN никто не отвечает. Это самая частая жалоба на удалённый доступ FRITZ!Box, и почти никогда виноват не сам туннель. Неверны план адресов, идентичность подсети или таблица маршрутизации клиента. Что именно вы будете отлаживать, зависит от того, выбрали вы WireGuard или более старый IPSec Fernzugang, поэтому начните с понимания того, что вы действительно настроили.
Туннель поднимается, а LAN молчит
Установленный туннель доказывает, что ключи и конечная точка верны. Но он не доказывает, что клиент получил адрес, на который коробка умеет маршрутизировать, и не доказывает, что клиент знает, какие префиксы относятся к туннелю. Это два разных успеха, и только второй позволяет добраться до принтера.
Сначала проверьте адрес клиента, затем его таблицу маршрутизации.
Если выданный адрес лежит вне подсети LAN, коробке некуда маршрутизировать обратно. Если он лежит внутри диапазона DHCP, коробка может выдать тот же адрес локальному устройству. И то и другое даёт туннель, который подключается, и LAN, которая вас игнорирует.
Что на самом деле настраивает каждый вариант
Вариант IPSec создаёт файл конфигурации для одного пользователя, содержащий предварительно общий ключ и адресацию. Вы импортируете его в клиент, который говорит на том же профиле, а в Windows это обычно инструмент производителя, а не встроенный клиент. Вариант WireGuard создаёт peer для одного устройства: пару ключей, адрес внутри туннеля и конечную точку.
Эта разница определяет вашу модель обслуживания. Каждое устройство WireGuard — отдельный peer со своим ключом, поэтому отзыв потерянного телефона означает удаление одного peer, пока остальные продолжают работать. IPSec отзывает, меняя общий секрет или конфигурацию пользователя, что грубее и затрагивает каждое устройство, которое его использует.
Ни один из вариантов не устарел. Путь через IPSec остаётся поддерживаемым там, где удалённая сторона не может запускать WireGuard.
Поля IPSec, которые дают мёртвый туннель
Четыре значения должны совпадать с вашей LAN, и три из них отказывают так, что это выглядит как сломанный туннель.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
Именно сетевой адрес чаще всего и путают. Подсеть определяется своим первым адресом, который обычно заканчивается нулём, и ввод адреса хоста в это поле даёт конфигурацию, которая выглядит совершенно правдоподобно и никогда не подключается. Диапазон DHCP важен по другой причине: клиентам туннеля обычно выдаются адреса выше него, поэтому диапазон, съедающий всю подсеть, не оставляет ничего для раздачи.
Перекрывающиеся подсети — второй классический случай. Если удалённая LAN, к которой вы подключаетесь, использует тот же префикс, что и LAN, на которой вы сидите, маршрутизация не может их различить, и перенумерация одной стороны — единственное настоящее решение. Никакое количество клиентской конфигурации этого не решает.
Почему WireGuard отказывает иначе
В WireGuard нет предварительно общего ключа, который можно опечатать, поэтому его отказы группируются вокруг определения peer. Список разрешённых IP, в котором пропущен префикс LAN, даёт туннель, который ничего не несёт, потому что клиент никогда не отправляет в него трафик, направленный в LAN. Устаревший открытый ключ на любой стороне даёт рукопожатие, которое никогда не завершается. Отсутствующая конечная точка или неверный порт дают тишину вместо ошибки.
Сравните обе стороны поле за полем, вместо того чтобы импортировать файл снова и надеяться.
Единственный общий отказ — столкновение подсетей. WireGuard охотно построит туннель к сети, которая перекрывается с вашей локальной, и тогда таблица маршрутизации решает, какой из двух одинаковых префиксов победит.
Докажите это снаружи, а затем оставьте путь обратно внутрь
Проверяйте с мобильного подключения, никогда изнутри LAN, потому что изнутри вы проверяете путь, который вообще не задействует туннель. Запишите, какой порт использует каждый вариант, прежде чем включать его, и переадресуйте этот порт на коробку.
Держите созданный файл там, куда вы попадаете без туннеля, и заодно запишите внешнее имя коробки.
Конфигурация, которую ни разу не проверяли снаружи, — это план, а не работающий путь удалённого доступа. Проверяйте один хост LAN по адресу, а не по имени, чтобы отказ DNS не приняли за отказ маршрутизации.