에코 응답은 오고 원격 데스크톱도 동작하는데, 브라우저는 포기할 때까지 빈 페이지에 머문다. 이 패턴에는 두 가지 설명이 맞는데, 그것들은 한 문제의 변형이 아니며, 서비스를 한 번도 허용하지 않은 정책이거나 전송이 커지면 더는 들어맞지 않는 패킷이다. 에코 응답은 둘 다 배제하지 않는다.

가장 작은 질문에서 가장 큰 질문으로 나아가며, 각 단계가 실제로 무엇을 증명했는지 적어라.

에코 응답은 훨씬 작은 질문에 답한다

에코 응답은 목적지의 IP 스택이 당신의 출발지에서 온 ICMP 요청에 응답했다는 뜻이다. 필요한 포트에 TCP 리스너가 있는지, 정책이 그 포트를 허용하는지, 목적지 호스트가 게이트웨이와 무관하게 트래픽을 필터링하는지는 말해 주지 않는다. 한 서비스를 허용하는 게이트웨이가 다른 서비스를 떨어뜨릴 수 있으며, 두 대상 모두 핑에 응답할 수 있다. 응답을 하나의 패킷과 하나의 방향에 관한 하나의 사실로 읽어라.

다른 무엇을 해석하기 전에 목적지와 서비스 포트를 확인하라. 시험한 주소와 애플리케이션이 쓰는 주소가 서로 다른 레코드인 경우가 있고, 이름이 두 주소로 해석되면 그럴 가능성이 높다.

연결이 시작되었는지 확인하라

즉시 거부되는 연결은 리스너나 정책의 답으로, 무언가가 응답하며 아니라고 말한 것이다. 열린 뒤 데이터가 움직이기 시작할 때 멈추는 연결은 크기를 가리킨다. 핸드셰이크를 아예 끝내지 못하는 연결은 보통 정책이나 라우팅 문제이며, 거부보다는 시간 초과처럼 보인다.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU 설정을 건드리기 전에 그 세 가지 중 무엇을 보았는지 기록하라. 거부된 연결을 고치려고 터널 크기를 바꾸면 그 변경이 낭비되고 진짜 원인을 한동안 가린다.

명시한 숫자로 크기를 측정하라

부하에서 멈춤이 나타나면, 단편화 금지 비트를 켜고 패킷 크기 하나를 시험하고 결과가 의미를 갖도록 산수를 제시하라. iputils가 있는 Linux에서 1392바이트 페이로드에 8바이트 ICMP 헤더와 20바이트 IPv4 헤더를 더하면 정확히 1420바이트의 내부 패킷이 된다. 게이트웨이에 도달하는 맨 핑은 애플리케이션에 관해 아무것도 증명하지 못하므로 이 산수를 티켓에 적어라.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

두 검사는 측정 지점이지 터널 크기 권고가 아니다. 경로 어딘가에서 ICMP가 필터링되면, 필터링과 너무 큰 패킷이 클라이언트 쪽에서 똑같이 보이므로 시간 초과는 크기에 관해 아무것도 말해 주지 않는다. 성공도 반대 방향이나 다른 목적지에 관해 아무것도 말해 주지 않는다.

바깥 경로를 계산에 넣어라

캡슐화는 자체 헤더를 더하므로 회선 위의 패킷은 터널 안에서 측정한 패킷보다 크다. 두 패킷의 차이가 동작하는 작은 요청과 실패하는 큰 요청을 동시에 가능하게 만든다.

IPv4의 경로 MTU 탐색은 단편화 없이 전달할 수 없는 패킷에 관한 피드백에 의존하고, IPv6는 Packet Too Big 메시지를 쓴다. IPv4 명세가 그 메커니즘을 설명한다. 피드백을 필터링하면 송신자가 배울 능력이 깨지고, 절대 들어맞지 않을 패킷을 계속 재전송하게 된다. 그래서 동작하는 작은 요청과 실패하는 큰 요청이 그렇게 편하게 공존한다.

숫자 하나를 바꾸고 애플리케이션을 다시 시험하라

터널 MTU를 낮추거나 TCP의 최대 세그먼트 크기를 제한한 뒤, 검사가 아니라 원래의 애플리케이션 시험을 반복하라. 변경 후 성공하는 검사와 여전히 멈추는 애플리케이션은 모양이 비슷한 다른 문제이고, 애플리케이션 시험만이 둘을 구분한다.

변경 기록에 측정한 크기, 가정한 추가 비용, 설정한 값을 산수로 남겨라. 나중에 검토하는 사람은 핑 스크린샷에서 가정을 다시 끌어내는 대신 검증할 수 있다.

시험한 모든 크기에서 애플리케이션이 동작한다면 숫자 조정을 멈추고, 동작하는 서비스와 실패하는 서비스를 가르는 정책을 보라.

관련 글