Нет интернета после удаления VPN? Проверьте трёх владельцев
Оставшийся адаптер, фильтр или маршрут могут пережить клиент. Проверьте трёх владельцев, удалите самый узкий объект, затем снова проверьте прямой доступ и доступ через туннель.
Клиент исчез, а машина по-прежнему никуда не попадает, что соблазняет сровнять брандмауэр и начать заново. Не делайте этого. Блокирующее состояние может приходить от трёх разных владельцев на одной машине, и у каждого свой путь удаления. Слив всего сразу удаляет объект, от которого вы хотели избавиться, вместе с защитой, которая вам ещё нужна, и вдобавок уничтожает доказательство того, какой владелец вызвал проблему. Пять проверок по порядку не позволяют этому случиться.
Проверка 1: что ещё осталось и для чего это
Ищите три артефакта отдельно: виртуальный адаптер, который ещё существует, фильтр или правило брандмауэра, которое ещё блокирует, и маршрут или правило политики, которое ещё указывает на туннель, которого больше нет. Их наличие само по себе ничего не доказывает, потому что намеренный аварийный выключатель снаружи выглядит так же, как заброшенный.
Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block'
ip route show
ip -4 rule show
Запишите время, когда пропала связность, и может ли обычный клиент ещё запустить свой туннель. Если клиент может восстановить туннель и трафик возвращается, блокировка делает свою работу, а проблема в состоянии клиента, а не в оставшемся правиле.
Проверка 2: какой владелец это контролирует
У каждого артефакта есть владелец. Виртуальный адаптер принадлежит VPN-клиенту или его драйверу. Фильтр может принадлежать клиенту, собственному брандмауэру платформы или управляемому продукту безопасности. Маршрут мог быть установлен клиентом при подключении и оставлен.
На управляемом оборудовании проверьте политику устройства, прежде чем что-то трогать. Фильтр, навязанный политикой, будет восстановлен при следующей регистрации, так что локальное удаление покупает час и отчёт о соответствии. Этот разговор для администратора, а не для интерфейса брандмауэра.
Проверка 3: удалите самую узкую вещь, которая это объясняет
Начните с поддерживаемого поставщиком пути: ремонтная установка или правильное удаление часто корректно очищают созданное состояние, включая фильтры, которые ручное удаление пропустило бы. Прочитайте инструкции по восстановлению для установленной версии, потому что порядок важен и удаление после неудачного удаления ведёт себя иначе.
Если ручная проверка действительно необходима, запишите имя правила, интерфейс и заявленную цель, прежде чем что-то менять, и удалите этот объект по имени. Удаление каждого сетевого адаптера или слив всего набора правил ради одного клиента — это путь, на котором обращение в поддержку превращается в пересборку.
Проверка 4: DNS и маршруты переживают адаптеры
Состояние разрешения имён может пережить туннель. Резолвер, который всё ещё указывает на адрес внутри туннеля, которого больше нет, создаёт тайм-ауты, выглядящие точно как сброс брандмауэром, и обычный вывод здесь неверен.
resolvectl status
ip route get 1.1.1.1
nslookup example.com
Если адрес разрешается и сырое соединение по IP работает, DNS — оставшаяся проблема, а не фильтрация. Если не работает и то и другое, вернитесь к проверке первой с маршрутом и фильтром в руках.
Проверка 5: проверьте оба пути заново и верните диагностику
Сначала проверьте обычную связность, затем каждый оставшийся профиль VPN через его собственные элементы управления: подключитесь, используйте, отключитесь и убедитесь, что хост вернулся к простой связности. Этот круг — тот тест, который доказывает, что заброшенная блокировка исчезла, а не просто обойдена.
Наконец, восстановите любые диагностические изменения, сделанные по пути. Успешная очистка удаляет одну заброшенную зависимость; она не удаляет общую защиту хоста и не должна оставлять после себя навсегда ослабленный брандмауэр. Отметьте, какой владелец держал блокировку, потому что следующее удаление даст тех же трёх кандидатов.