VPN이 끊겼는데 인터넷이 계속 차단됨: 스위치인가 오래된 규칙인가?

터널이 닫히고 브라우저가 멈추는데 같은 Wi-Fi의 다른 기기는 모두 작동한다면 라우터는 원인이 아니다. 이 패턴에는 차단하라는 명령을 받은 킬 스위치, 제거된 클라이언트가 남긴 상태, 복구되지 않은 리졸버나 경로라는 세 가지 가능한 주인이 있다. 브라우저 창에서는 똑같아 보이지만 필요한 수리는 다르다. 네트워크 재설정을 실행하기 전에 어느 경우인지 판단하자.

아주 다른 두 가지 차단된 인터넷

의도된 차단은 기능으로, 활성 터널이 없을 때 클라이언트가 트래픽을 버려 보호된 경로 밖으로 아무것도 새지 않게 한다. 우발적 차단은 클라이언트 종료 후 남은 규칙, 기기 또는 리졸버 설정이다. 하나는 연결하거나 정책을 의도적으로 끄면 고쳐지고, 다른 하나는 남은 것을 정리하면 고쳐진다.

차이는 브라우저가 아니라 오류에 나타난다. 의도된 차단은 보통 즉시 거부되거나 조용히 멈추는 반면, 남은 리졸버는 리터럴 주소로 ping이 통해도 계속되는 이름 확인 실패를 만든다. 어느 쪽도 다른 기기에까지 영향을 주는 끊긴 Wi-Fi 연결과 같지 않다. 그 차이에 따라 먼저 리터럴 주소, 그다음 이름 순으로 점검하자.

클라이언트가 연결 해제 시 약속한 것

많은 제품이 일시 중지와 완전 중지를 구분하므로 연결 해제의 의미는 클라이언트 자체 설정에서 읽어야 한다. 일시 중지는 설계상 차단을 그대로 두고, 중지는 그것을 해제할 수 있다. 일부 모바일 플랫폼은 VPN이 연결되지 않을 때마다 트래픽을 차단하는 항상 켜짐 규칙으로 같은 개념을 표현한다.

조직이 보호를 요구하는 곳에서는 차단을 우회하는 것이 아니라 올바른 프로필에 다시 연결하는 것이 수리이며, 서버 이름이 여전히 확인되고 배포가 문서화한 예외를 통해 엔드포인트에 도달할 수 있는지 확인해야 한다. 실패한 재연결은 지속적인 차단과 똑같아 보이기 때문이다.

중단된 제거가 남긴 오래된 상태

중단된 설치 제거, 또는 터널이 켜진 동안 제거된 패키지는 방화벽 체인, 라우팅 규칙, 리졸버 항목 또는 가상 어댑터를 남길 수 있다. 프로세스는 사라졌지만 영향은 남았다.

애플리케이션이 지원하는 정리 및 복구 경로로 시작하고, 삭제하기 전에 어느 구성 요소가 남은 각 개체를 설치했는지 확인하자. 호스트 방화벽을 끄면 브라우징은 돌아오지만 무관한 보호도 함께 사라진다. 전역 네트워크 재설정은 원인을 밝히지 않고 작동하는 사무실이나 Wi-Fi 설정을 버리기 때문에 더 나쁘다.

클라이언트가 두 개 설치되어 있다면 어느 쪽이 정책을 소유하는지 정하자. 소유자가 둘이면 차단은 둘 다 제거해도 살아남는다.

브라우징만이 아니라 연결 해제된 상태를 검증하라

브라우징이 다시 되는 것은 약한 인수 테스트다. 필요한 정책이 온전하고 다른 무엇도 조용히 약화되지 않았는지 검증하자.

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

라우팅 규칙, 리졸버, 방화벽 정책을 깨끗하게 연결 해제된 기기의 모습과 비교하자. 그런 다음 정상 워크플로로 다시 연결하고 해제하며 읽기를 반복해, 예상 상태를 기억이 아니라 기록으로 남기자.

그 전후 쌍을 티켓에 남기자. 차단된 브라우저를 보는 다음 사람에게는 어느 클라이언트가 최선인지에 대한 또 하나의 의견보다 그것이 더 필요할 것이다.