VPN을 켰을 때만 일부 사이트가 열리지 않는 이유는 무엇일까요?

한 사이트만 실패하고 나머지가 모두 로드된다는 것은 터널이 트래픽을 전달한다는 증거이며, 대부분이 예상하는 것보다 문제 범위를 훨씬 좁혀 줍니다. 세 가지 관찰, 즉 HTTP 응답을 받았는지, 호스트 이름이 주소로 확인되었는지, 작은 요청은 통과하는데 큰 요청은 멈추는지가 나머지를 정리합니다. 이 답을 얻기 전에 VPN을 의심하면 보통 고장을 없애기보다 위치만 옮깁니다.

관찰은 순서대로 처리하세요. 응답한 사이트가 동시에 확인에 실패했을 수는 없으므로, 아무것도 로드되지 않는다면 다른 갈래에 있고 연결되었지만 인터넷이 없는 경우의 점검을 적용해야 합니다.

오류 메시지가 갈래를 고르게 하세요

거부, 봇 검사, 오류 페이지는 서비스가 응답했다는 뜻이고, 패킷이 애플리케이션에 도달해 돌아왔다는 뜻입니다. 그러면 문제는 출구 주소, 계정, 또는 공개하지 않은 요청 패턴을 따질 수 있는 사이트의 접근 정책으로 옮겨 갑니다. 이름 확인 실패는 사이트에 아예 도달하지 않았으므로 먼저 살펴볼 것은 주소입니다. 타임아웃은 무언가 보내졌지만 아무것도 확인해 주지 않은, 그 사이의 상태입니다.

인증서 경고는 네 번째 갈래에 속합니다. 브라우저가 신원을 확인할 수 없는 무언가가 연결에 응답했다는 뜻이며, 사용자 쪽 프록시이거나 클릭해서 넘어가서는 안 되는 실제 불일치입니다. 이것은 라우팅 문제가 아니라 신뢰 문제로 다루세요.

응답하는 사이트는 터널이 깨졌음을 증명하지 않습니다

응답이 차단 페이지라면 브라우저와 장비를 그대로 둔 채 두 번째 출구로 같은 페이지를 비교하세요. 결과가 출구 주소를 따라간다면 사이트가 그 주소를 다르게 취급하는 것이고, 어떤 클라이언트 설정도 이를 바꾸지 못합니다. 차단이 브라우저를 따라간다면 원인은 확장 프로그램, 저장된 프록시, 리졸버 설정에 있습니다. 두 번의 실행으로 이런 설명들을 저렴하게 구분할 수 있습니다.

브라우저에서만 생기는 실패는 흔하므로 일찍 시험할 가치가 있습니다. 한 지원 브라우저에서는 로드되고 다른 브라우저에서는 실패하는 페이지는 프로필 상태, 콘텐츠 차단기, 또는 브라우저 내부에 설정된 암호화 DNS를 가리킵니다. Chrome의 안전한 DNS 안내에 그 설정의 위치가 나오며, 지원되는 컨트롤로 바꾸는 것이 기기를 초기화하는 것보다 낫습니다.

큰 전송만 멈출 때는 패킷 크기를 보세요

헤더를 그린 뒤 멈추는 페이지는 아예 시작하지 않는 페이지와 다른 서명을 가집니다. 작은 응답은 통과하는데 전체 크기 페이로드가 송신자에게 아무 신호도 보낼 수 없는 지점에서 버려지는 것이 브라우저에서 보이는 경로 MTU 고장의 모습입니다. 필터링을 논하기 전에 같은 호스트로 작은 요청과 큰 요청을 보내 비교하세요. 경로 MTU 탐색은 경로상 가장 작은 링크 크기를 배워야 하며, 필터링된 네트워크가 흔히 버리는 ICMP 피드백에 의존합니다.

그 가설은 한 번의 ping이 아니라 크기를 훑어 시험하세요. 일정한 페이로드 크기에서 시작하는 실패는 강한 증거이지만, 위치가 옮겨 다니는 실패는 그렇지 않습니다.

실패한 요청에서 수정을 확인하세요

캐시된 겉껍질은 그려지더라도 로그인 뒤의 API 호출은 여전히 실패할 수 있으므로, 홈페이지가 아니라 원래 작업을 다시 시험하세요. 아래 명령은 같은 호스트에 대해 이름 확인, 작은 요청, 큰 요청을 구분합니다. 호스트 이름과 경로는 실제로 깨진 요청의 것으로 바꾸세요.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

dig 응답이 브라우저가 쓴 것과 다르다면 변수는 리졸버이고, 살펴볼 곳은 브라우저 자체의 DNS 설정입니다. 작은 요청이 상태를 반환하는데 큰 요청이 멈춘다면 패킷 크기 갈래를 처리하세요. 둘 다 시간 초과되면 출구 경로와 그 주소에 대한 사이트의 처리가 다시 논의 대상이 됩니다.

원래 요청을 성공시킨 변경만 남기고 나머지는 되돌리세요. 브라우저, 리졸버, 클라이언트에 동시에 변경을 쌓으면 어느 것이 효과가 있었는지 말할 수 없게 됩니다.