DNS 실패일까 MTU 문제일까? 요청이 실제로 어디서 멈추는가

두 가지 실패는 사용자에게 같은 말로 나타난다. 사이트가 안 된다는 말이다. 하지만 생기는 계층이 다르고, 그 차이가 무엇을 바꿔야 하는지를 결정한다. 이름 해석 실패는 어느 연결도 존재하기 전에 멈춘다. 패킷 크기 실패는 이름이 해석되고 핸드셰이크가 끝난 뒤에 생기므로 페이지가 로딩을 시작하다가 멈춘다. 설정을 찾기 전에 단계를 찾아야 한다.

서로 다른 계층에서 생기는 두 가지 실패

해석은 이름을 주소로 바꾸는 일이며, 이것이 성공하기 전에는 연결의 다른 무엇도 시작될 수 없다. 경로 MTU 문제는 더 나중에, 어느 링크의 한계보다 큰 패킷이 버려지고 그 사실이 송신자에게 전달되지 않을 때 생긴다. 하나는 조회이고, 다른 하나는 특정 크기 위에서만 나타나는 전달 실패다.

증상은 도구 없이도 관찰할 수 있는 방식으로 다르다. DNS 실패는 즉각적이고 일관된다. 브라우저가 서버를 찾을 수 없다고 말한다. MTU 실패는 부분적이다. 페이지가 시작되고 일부 자원이 도착하며 큰 응답이나 업로드가 멈춘다.

증상이 부분적이라면 DNS를 보는 것을 그만두어라.

단계 1: 이름이 해석되기는 하는가

응용 프로그램이 쓰는 것과 똑같은 호스트 이름으로 그 환경의 조회 도구를 사용한다. 사무실의 사설 이름은 내부 리졸버를 요구할 수 있고, 브라우저 자체의 보안 DNS는 운영 체제의 리졸버와 다르게 동작할 수 있어 둘이 같은 이름에 대해 엇갈릴 수 있다.

운영 체제가 쓸 리졸버에 물어보고, 그다음 비교한다.

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

해석이 실패한다면 문제는 그 정책과 도달성에 있다. 비교를 얻기 위해서만 사설 이름을 임의의 공개 리졸버로 보내지 마라. 비교 자체가 내부에 두려던 이름을 흔리기 때문이다.

단계 2: 전송이 어디서 멈추는가

이름이 해석되고 연결이 시작되면 작업이 어디서 멈춄는지 기록한다. 표시된 뒤 한 자원에서 멈추는 페이지, 일정한 지점에서 죽는 업로드, 작은 요청은 되는데 끝나지 않는 큰 다운로드는 모두 크기 모양의 증상이다. 전혀 시작되지 않는 응답은 다른 모양이다.

비교하는 동안 끝점과 응용 프로그램의 목적지를 고정하라. 그렇지 않으면 두 변수를 동시에 재는 셈이다. 이 단계에서도 다른 원인은 가능하다. 서비스 오류, 손실, 필터 동작, 터널 재접속은 모두 정체를 만든다.

재현되는 정체 하나가 일화 열 개보다 값지다.

MTU가 핸드셰이크 이후에만 해를 끼치는 이유

TCP 핸드셰이크는 작은 패킷을 쓰므로 전체 크기 세그먼트를 실을 수 없는 경로에서도 성공한다. 실패는 송신자가 분할 금지 비트를 달고 큰 패킷을 보내고, 링크가 그것을 버리고, 한계를 알렸어야 할 ICMP 메시지가 필터에 먹혀 도착하지 않을 때 나타난다. 그러면 송신자는 같은 크기를 다시 시도하고 전송이 멈춘다.

그래서 증상은 무작위가 아니라 크기에 의존하고 재현된다. 이것은 호스트에 핑을 보내는 것이 아무것도 증명하지 못하는 이유이기도 하다. 작은 ICMP 에코는 전체 크기 부하를 실을 수 없는 경로를 지나갈 수 있기 때문이다. 가능하면 경로 양 끝에서 크기를 재라. 한 방향에서만 나타나는 한계는 터널의 MTU가 아니라 경로의 비대칭이다.

추론하지 말고 크기를 분명히 재라.

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

한 계층을 바꿀 다음 증명하라

이름에 대해서는 리졸버 정책을 바꾸고 같은 조회를 다시 실행한다. 크기에 대해서는 원래 값을 기록하고 되돌릴 준비를 한 상태에서 MTU 절차 를 사용한다. 터널의 실제 MTU를 모른 채 MSS를 조이면 한 정체를 다른 정체와 맞바꾸기 때문이다.

여러 설정을 바꾼 뒤 한 번 로드된 페이지는 무엇이 고쳤는지 알려 주지 않는다. 한 가지만 바꾸고 같은 시험을 다시 실행하며, 결과를 처음 기록한 실패 단계 옆에 둔다.

그 기록이 바로 DNS와 패킷 크기와 인증을 아무도 설명할 수 없는 영구적인 우회책 더미로 만들지 않게 막는 것이다. 원시 IP로 시험하는 것은 TLS 신원을 바꾸는 지름길의 좋은 예이며, 비교를 통과시키려고 인증서 검증을 끄는 것은 진단이 아니다.