Немає інтернету після видалення 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 через його власні елементи керування: підключіться, скористайтеся, відключіться і переконайтеся, що хост повернувся до простої зв’язності. Цей оберт — той тест, який доводить, що закинуте блокування зникло, а не просто обійдене.

Нарешті, відновіть будь-які діагностичні зміни, зроблені по дорозі. Успішне очищення видаляє одну закинуту залежність; воно не видаляє загальний захист хоста і не повинно залишати по собі назавжди ослаблений брандмауер. Позначте, який власник тримав блокування, бо наступне видалення дасть тих самих трьох кандидатів.