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 클라이언트나 그 드라이버의 것입니다. 필터는 클라이언트, 플랫폼 자체의 방화벽, 또는 관리형 보안 제품의 것일 수 있습니다. 경로는 클라이언트가 연결할 때 설치하고 남겨 두었을 수 있습니다.

관리형 장비에서는 무엇이든 만지기 전에 장치 정책을 확인하세요. 정책으로 강제되는 필터는 다음 체크인에서 복원되므로, 로컬 제거는 한 시간과 규정 준수 보고서를 사는 셈입니다. 그 대화는 관리자의 것이지 방화벽 UI의 것이 아닙니다.

점검 3: 그것을 설명하는 가장 좁은 것을 제거하세요

공급업체가 지원하는 경로부터 시작하세요: 복구 설치나 올바른 제거는 수동 제거가 놓칠 필터를 포함해 생성된 상태를 제대로 정리하는 경우가 많습니다. 설치된 버전의 복구 지침을 읽으세요 — 순서가 중요하고, 잘못된 제거 후의 제거는 다르게 동작합니다.

수동 점검이 정말로 필요하다면 무엇이든 바꾸기 전에 규칙 이름, 인터페이스, 선언된 목적을 기록하고 그 개체를 이름으로 제거하세요. 클라이언트 하나를 겨냥해 모든 네트워크 어댑터를 제거하거나 규칙 집합 전체를 밀어내는 것은 지원 사례가 재구축으로 바뀌는 길입니다.

점검 4: DNS와 경로는 어댑터보다 오래 산다

확인 상태는 터널보다 오래 살 수 있습니다. 더 이상 존재하지 않는 터널 내부 주소를 아직 가리키는 리졸버는 방화벽 드롭과 똑같이 보이는 시간 초과를 만들어 내고, 흔한 결론은 틀립니다.

resolvectl status
ip route get 1.1.1.1
nslookup example.com

주소가 확인되고 IP로 직접 연결이 되면 남은 문제는 필터링이 아니라 DNS입니다. 둘 다 실패하면 경로와 필터를 들고 첫 번째 점검으로 돌아가세요.

점검 5: 두 경로를 다시 테스트하고 진단을 제자리에 돌려놓으세요

먼저 일반 연결을 확인하고, 다음으로 남은 각 VPN 프로필을 자체 제어로 확인하세요: 연결하고, 사용하고, 연결을 끊고, 호스트가 일반 연결로 돌아왔는지 확인하십시오. 그 왕복이 버려진 차단이 단순히 우회된 것이 아니라 사라졌음을 증명하는 테스트입니다.

마지막으로, 도중에 수행한 진단 변경을 복원하세요. 성공한 정리는 버려진 의존성 하나를 제거할 뿐, 호스트의 일반 보호를 제거하지 않으며 영구적으로 느슨해진 방화벽을 남겨서도 안 됩니다. 어느 소유자가 차단을 쥐고 있었는지 기록하세요 — 다음 제거에서도 같은 세 후보가 나옵니다.