Няма интернет след деинсталиране на 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 профил през собствените му контроли: свържете се, използвайте го, прекъснете и потвърдете, че хостът се е върнал към обичайната свързаност. Този кръг е тестът, който доказва, че изоставеното блокиране е изчезнало, а не само заобиколено.

Накрая възстановете всяка диагностична промяна, която сте направили по пътя. Успешното почистване премахва една изоставена зависимост; то не премахва общата защита на хоста и не бива да оставя след себе си трайно отслабена защитна стена. Отбележете кой собственик е държал блокирането, защото следващото деинсталиране ще даде същите три кандидата.