인증을 통과하고 ping을 운반한 뒤 첫 대용량 전송에서 멈추는 터널은 고장 난 VPN이 아니라 사라진 ICMP 메시지의 전형적인 징후입니다. 송신자는 패킷이 너무 컸다는 사실을 알지 못한 채 같은 크기를 재시도하고 애플리케이션은 기다립니다. 이를 고치는 것은 방화벽 정책의 결정이며 클라이언트 재설치가 아닙니다. 순서가 중요합니다. 먼저 크기 경계가 어디인지 측정하고, 그다음 보고서를 삼킨 규칙을 좁힙니다.

이 경로에서 ICMP가 실제로 나르는 것

IPv4 경로 MTU 탐색 은 don't-fragment 비트가 설정된 패킷을 전달할 수 없었다고 라우터가 보고하는 것에 의존합니다. 그 보고가 ICMP Fragmentation Needed 메시지이며, 그것이 없으면 송신자는 세그먼트 크기를 줄일 이유가 없습니다. IPv6는 더 엄격합니다. 라우터는 전송 중에 분할하지 않으므로 ICMPv6 Packet Too Big 메시지만이 송신자를 줄어들게 하는 신호입니다.

두 메시지 모두 제어 평면의 피드백이며 어느 것도 진단용 에코가 아닙니다. ping을 차단하는 정책과 모든 ICMP를 차단하는 정책은 규칙 목록에서는 비슷해 보이지만 네트워크에서는 매우 다르게 동작합니다. 후자는 올바르게 크기가 맞춰진 터널을 체인에서 가장 작은 링크보다 큰 모든 것에 대해 단방향 경로로 바꿀 수 있습니다.

일부 전송 계층은 RFC 4821이 설명하듯 탐사 패킷으로 자체 탐색을 구현하며, 이 피드백에 덜 의존합니다. 이는 어떤 전송을 실행하는지 확인해야 할 이유이지, 모든 터널이 면역이라고 가정할 이유가 아닙니다.

메시지경로상의 목적차단되면
ICMPv4 유형 3 코드 4패킷이 다음 링크에 비해 너무 컸다송신자가 계속 재시도하다가 멈춘다
ICMPv6 유형 2Packet Too Big, IPv6의 대응물같은 정지, 분할 대체 수단 없음
ICMP 유형 11시간 초과, traceroute가 사용진단이 홉을 잃지만 트래픽은 계속 흐른다
ICMP 에코 요청과 응답도달 가능성 테스트ping은 실패하지만 경로는 정상일 수 있다

실패는 크기에 의존한다

실패가 패킷 크기와 상관관계가 있는지 물어보십시오. 로그인 페이지, DNS 쿼리, 짧은 API 호출은 성공하지만 파일 업로드, 큰 응답, 이미지 다운로드는 멈춥니다. 이 패턴은 두 끝 사이 어딘가의 크기 한계를 가리키며 인증이나 라우팅의 문제가 아닙니다. 작은 ping의 성공은 그 경계가 어디에 있는지에 대해 거의 아무것도 말해 주지 않습니다.

터널 내부에는 고려해야 할 두 계층이 있습니다. 페이로드 패킷과 외부 캡슐화된 패킷입니다. 내부 송신자가 올바르게 동작하더라도 외부 경로가 터널이 가정한 것보다 작을 수 있으며, 그래서 터널 자체의 MTU 설정과 그 아래의 물리적 링크가 모두 중요합니다.

규칙을 편집하기 전에 측정하라

don't-fragment 비트와 직접 고른 페이로드 크기로 탐사하라, 고장 난 클라이언트에서 보호된 주소 쪽으로:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472바이트 페이로드에 28바이트 헤더를 더하면 1500바이트 패킷이 됩니다. 큰 탐사가 분할 오류로 실패하고 작은 탐사가 통과하면 경계를 찾은 것입니다. 터널 오버헤드를 고려해 조정하고 작동하는 크기가 안정될 때까지 반복하십시오.

그다음 간극이 보고서 자체인지 확인하십시오. 탐사가 오류도 응답도 없이 조용히 실패하면 메시지는 전달되지 않고 버려지고 있을 가능성이 크며, 의심 대상은 규칙입니다.

규칙을 좁힌 다음 작업을 다시 테스트하라

수정은 전체 프로토콜이 아니라 특정 제어 메시지를 허용해야 합니다. iptables 호스트에서 형태는 유형별 허용입니다. 구문은 사용하는 플랫폼에서 방화벽을 관리하는 것에 맞게 조정하십시오:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

로컬 정책이 그렇다면 에코 응답은 차단된 채로 두십시오. 경로가 필요로 하는 것은 그것이 아니기 때문입니다. 그런 다음 원래 실패했던 전송을 새 연결에서 다시 테스트하고, 규칙 카운터가 메시지가 도착하는 것을 보여 주는지 확인하십시오.

메시지를 허용한 뒤에도 대용량 전송이 멈춘다면 남은 한계는 다른 곳에 있습니다. 너무 높게 설정된 터널 MTU, 패킷을 다시 쓰는 프록시, 또는 보고하는 대신 버리는 중간 장치입니다. ICMP 규칙은 필요했지만 충분하지는 않았습니다.

관련 글