Интернет работает только с приложением VPN? Проверьте четыре уровня
В Windows приложение VPN оставляет прокси, виртуальный адаптер, маршруты и DNS. Пройдите четыре уровня с командами для Linux и macOS.
Вы пробуете бесплатный VPN-клиент или расширение браузера неделю, выключаете его, и интернет пропадает. Значок Wi-Fi по-прежнему показывает подключение, другие устройства на том же роутере работают, а вернуть просмотр помогают только повторное включение приложения или его удаление. Это не шифрование создаёт зависимость. Это настройка, которую приложение записало там, где туннель ею не владеет.
Клиент меняет настройки, которыми туннель не владеет
Клиент приватности в Windows или macOS обычно трогает три места сразу. Он задаёт системный HTTP-прокси — то же поле, которое показывает «Свойства обозревателя». Он устанавливает виртуальный адаптер, часто драйвер TAP, чтобы перехватывать пакеты. И он переписывает список резолверов, тогда как при нажатии отключения исчезает только туннель.
Расширение браузера — вещь более узкая. Обычно оно меняет свой профиль или прокси, которому следует один браузер. Поэтому один браузер может перестать работать, пока инструменты командной строки работают, или наоборот: у расширения никогда не было прав трогать остальные уровни. Какой уровень оно изменило, решает, какие инструменты сломаются.
В любом случае устаревшее решение приняло ПО, у которого не было причин его отменять. Туннель был видимой частью и единственной частью с чистой процедурой завершения. Всё остальное — настройка в хранилище, которое переживает процесс, поэтому удаление приложения — единственный шаг, который отменяет все три сразу. Чтение этих хранилищ до переустановки — то, что превращает симптом в диагноз.
Три остатка, три разные поломки
Первый остаток — прокси, который никуда не ведёт: галочка прокси локальной сети всё ещё стоит, или URL скрипта конфигурации указывает на порт localhost, где больше никто не слушает. Браузер отправляет каждый запрос на этот мёртвый порт и зависает, пока тайм-аут не станет похож на мёртвую сеть. Второй — адаптер, который всё ещё владеет маршрутом по умолчанию, потому что устройство TAP-Windows или драйвер маршрутизации поставщика остаётся настоящим интерфейсом после удаления. Он сохраняет выданный ему маршрут, и трафик пропадает в туннеле, которого нет. Ни один остаток не заявляет о себе; оба выглядят точно как авария.
Третий — DNS, и он отказывает раньше двух других. Если список резолверов содержит только серверы, доступные через туннель, каждый запрос истекает до того, как запрошена хотя бы одна страница, поэтому браузер сообщает о недоступном сайте, а не о мёртвом прокси. Какой бы из них у вас ни был, ни один не является аварией в сетевом смысле. Каждый — остаток, который никто не отозвал, и каждый чинится в другом месте.
Пройдите четыре уровня
Начните ближе всего к приложению и двигайтесь вниз, потому что уровни отказывают в этом порядке видимости. Меняйте один уровень за тест и проверяйте после каждого. Сброс всего сразу обычно возвращает просмотр и оставляет вас без ответа, какой остаток был причиной, поэтому следующая установка воссоздаёт ту же загадку. Порядок: прокси, адаптеры, маршруты, резолверы.
В Windows каждая проверка — одна команда, входящая в систему, поэтому ничего устанавливать не нужно. Выполните их по порядку и сохраните вывод вместе, потому что четыре ответа имеют смысл только рядом. Они сообщают прокси, адаптеры, маршруты IPv4 и список резолверов именно в этом порядке:
netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddressLinux и macOS нуждаются в своих командах, и они не взаимозаменяемы. В Linux маршруты берутся из ip route, а резолвер — из resolvectl status там, где им владеет systemd-resolved, с откатом к cat /etc/resolv.conf. В macOS маршруты берутся из netstat -rn, резолверы — из scutil --dns, а системный прокси — из scutil --proxy. Читатель macOS, запустивший ip route, получит command not found, а /etc/resolv.conf там — сгенерированная заглушка, а не авторитетная конфигурация. Проверьте платформу до проверки уровня, иначе первая команда станет находкой.
Для каждого уровня задайте один вопрос: это значение всё ещё указывает на что-то существующее, пока приложение закрыто? Прокси на мёртвом порту, адаптер без туннеля, маршрут по умолчанию через выключенный интерфейс и резолвер внутри туннеля — все отвечают нет. Любого одного нет достаточно, чтобы объяснить симптом, поэтому и важна одна смена за тест.
Прокси — не туннель
Прокси принимает запрос, забирает его в другом месте и возвращает ответ, а значит, знает пункт назначения и видит всё, что сайт не зашифровал сам. Он не переносит другие протоколы. Он не защищает путь, если пункт назначения уже не использует TLS. И его может изменить любой, кто его установил, без вашего участия.
Это различие меняет вопрос, который стоит задавать. Когда прокси остаётся, выясните, какая программа всё ещё направляет ваш браузер, а не работает ли туннель. Туннель может быть совершенно здоров и совершенно не относиться к поломке.
Если вы хотите знать, что такой клиент действительно сделал, наблюдайте за ним, а не читайте его панель. Process Monitor записывает, какие ключи реестра и файлы он трогает, а перехват пакетов показывает, куда ушёл его трафик. Оба — обычные инструменты, и оба отвечают на вопрос об остатке лучше любого индикатора состояния. Ни один не требует, чтобы приложение всё ещё работало.
Удалите компонент, а не доказательство
Долговечное исправление — удалить то, что записало настройку. Удалите приложение, удалите виртуальный адаптер, который оно добавило, очистите прокси и список резолверов, затем перезагрузитесь и проверьте, пока приложение всё ещё удалено. Если просмотр работает в этот момент, вы нашли причину, а не обходной путь. Запишите, какой уровень устарел, потому что тот же поставщик склонен дважды выпускать одну и ту же ошибку.
Если симптом возвращается после установки следующего клиента, пройдите четыре уровня снова, прежде чем решать, что служба что-то сломала. Доказательство обычно всё ещё там, в одном из четырёх мест. Второе приложение не создаёт пятый уровень; оно меняет один из четырёх.
Переустановка сбрасывает прокси, но не устаревший адаптер и может оставить два резолвера в списке. Эта асимметрия — причина, почему удалить, затем проверить лучше кнопки полного сброса. Она также даёт вам базу для сравнения в следующий раз, когда соединение упадёт.