Почему админка роутера перестаёт отвечать после изменения VPN

Вы изменили маршрут или правило брандмауэра, чтобы проверить туннель на роутере, и теперь страница администрирования не отвечает с ноутбука, который десять минут назад работал нормально. Рефлекс — винить VPN. Чаще всего туннель в порядке, а сломалось одно из трёх других: нет маршрута обратно на собственный адрес роутера, политика входа отбрасывает запрос, или веб-служба не слушает адрес, к которому вы обращаетесь. Все три выглядят в браузере одинаково, поэтому люди час перезапускают туннель и ничего не узнают.

Вот миф, который стоит убить первым: работающий туннель — не путь обратно внутрь. Это новое сетевое подключение со своими вопросами доверия, и оно может тихо убрать старый путь управления, открыв новый, который никто не проверял.

Туннель никогда не был путём управления

Пересылка и вход — разные задачи. «Может ли клиент дойти до NAS через туннель?» — вопрос пересылки о пакетах, проходящих через роутер. «Могу ли я открыть порт SSH роутера?» — вопрос входа о пакетах, адресованных самому роутеру. Правило пропуска, написанное для пересылаемого трафика, ничего не делает для второго, и это самая частая причина, по которой туннель, идеально несущий трафик, всё же отказывает вашей сессии администрирования.

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

Первый слой: есть ли маршрут к собственному адресу роутера?

Начните на клиенте и спросите ядро, куда пойдёт пакет. В Linux ip route get 10.6.0.1 печатает выбранный маршрут, исходящий интерфейс и адрес источника. Если он сообщает маршрут по умолчанию в сторону провайдера, пакет никогда не входит в туннель, и никакое правило на роутере его не спасёт.

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

Подтвердите точный адрес, которого вы собираетесь достичь, прежде чем отлаживать политику. Устаревшая запись DNS или кэшированная запись соседа с времён до изменения ведёт вас на адрес, которым роутер никогда не владел.

Второй слой: политика входа, а не политика пересылки

Брандмауэры оценивают правила на интерфейсе, куда приходит пакет. В pfSense и OPNsense вкладка интерфейса и порядок правил решают, разрешён ли трафик к собственным службам брандмауэра; правило, выпускающее клиентов LAN в интернет, не является правилом, позволяющим партнёру туннеля открыть веб-интерфейс. В OpenWrt с firewall4 каждая зона несёт политику входа, option input 'ACCEPT' или 'REJECT', и туннельный интерфейс в зоне со входом REJECT будет отклонять управляющие соединения, продолжая пересылать трафик, если пересылка разрешена.

Не отключайте правило защиты от блокировки, чтобы заработал новый путь. Это правило не даёт плохому правилу заблокировать адрес управления LAN; оно защищает подсеть LAN, а не подсеть туннеля, которую вы только что создали. Добавьте одно узкое правило для источника администратора и оставьте страховку в покое. Документация pfSense о доступе администратора объясняет, где находятся эти элементы управления.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Третий слой: слушает ли что-нибудь этот адрес?

Служба может работать и всё равно быть недоступной, потому что привязалась к одному адресу. uhttpd в OpenWrt держит явные записи прослушивания в /etc/config/uhttpd, например list listen_http '0.0.0.0:80'; сборка, которая привязывается только к адресу LAN, ничего не принимает на адресе туннеля, и продукты с настройкой интерфейса прослушивания ведут себя так же. Команды прослушивания выше отвечают на это напрямую.

Затем отделите отказ от тишины. nc -vz 10.6.0.1 443, возвращающая отказанное соединение, означает, что пакет дошёл до роутера и что-то его отвергло — либо закрытый порт, либо явное правило отказа. Зависание до тайм-аута означает, что пакет был отброшен или вообще не маршрутизирован. Это различие говорит, какой слой проверять дальше, и стоит пять секунд.

Интерфейс VPN — это граница, а не путь восстановления

Шифрование защищает провод; оно ничего не говорит о том, кому можно открывать страницу администрирования. Когда туннель заработает, сопротивляйтесь желанию решить доступность разрешением всего на туннельном интерфейсе. Дайте администраторам правило, привязанное к их собственному туннельному адресу, или отдельный туннель только для администраторов, и держите обычных пользователей, NAS, камеры и семейные ноутбуки подальше от порта управления. Партнёр, которому нужен общий доступ к файлам, не должен находиться в одном правиле от входа в роутер.

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

Компенсационный шаг, который люди делают после блокировки, хуже: включение администрирования через WAN или перенаправление порта на веб-интерфейс. Это превращает короткий сбой в постоянную экспозицию, и страница входа становится доступной любому сканеру в интернете. Тестируйте и запрещённую сторону, а не только разрешённую, чтобы партнёр, которому не положен административный доступ, получал тайм-аут или отказ вместо запроса на вход.

Тестируйте и новым соединением. Брандмауэр с отслеживанием состояний держит существующие потоки в своей таблице состояний, поэтому уже открытая сессия SSH может пережить изменение, блокирующее каждое новое соединение. Так блокировка остаётся незаметной до следующей перезагрузки или следующего сна ноутбука.

Подготовьте обратный путь, прежде чем трогать политику

Запишите четыре вещи до первого изменения: как вы доберётесь до устройства, если туннель умрёт, например через последовательную консоль, консоль провайдера или машину в LAN; куда экспортируется текущая конфигурация; какое одно правило или маршрут вы собираетесь изменить; и как вернёте именно этот элемент. В OpenWrt sysupgrade -b /tmp/backup.tar.gz снимает конфигурацию, а правки остаются в ожидании до uci commit, что даёт дешёвую отмену, если заметить вовремя. pfSense ведёт историю конфигурации, а AutoConfigBackup помогает, только если он уже был включён. Если роутер работает с набором правил fail-closed, убедитесь, что запланированный путь обслуживания не находится внутри трафика, который блокирует это правило, и помните, что перезагрузка заново применяет постоянные правила, а не стирает их.

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

Быстрая проверка перед уходом:

• Достаёте ли вы до роутера из источника, не зависящего от только что изменённого правила?
• Разрешает ли политика входа на туннельном интерфейсе только источник администратора?
• Привязана ли служба управления к адресу, который существует в туннеле?
• Проверили ли вы одного запрещённого партнёра и одну новую сессию?
• Поверхность администрирования через WAN всё ещё закрыта?