중첩 VPN 터널: 큰 패킷에서 안쪽 터널이 멈추는 이유

DNS는 해석되고 SSH 세션은 유지되는데, 큰 업로드만 멈추고 같은 호스트로의 ping은 여전히 응답합니다. 이 분리는 고장 난 터널이 아니라 패킷 크기를 가리킵니다. 중첩 터널은 어느 한 터널만으로는 도달하지 못할 크기에서 그 지점에 이릅니다. 내부 세션은 멀쩡하고, 더 이상 들어가지 않는 패킷을 넘겨받을 뿐입니다.

경로 MTU는 실제로 어디로 가는가

캡슐화할 때마다 다음 계층이 순서를 받기 전에 바이트를 씁니다. 이더넷 경로는 바깥 패킷에 1500바이트를 주고, 바깥 터널은 그 안의 무엇이든 주소를 얻기 전에 자기 몫을 가져갑니다. 추측한 오버헤드 값 하나는 중요한 만큼 정확히 틀립니다.

계층을 순서대로 나열하십시오: 접속 경로, 바깥 전송, 바깥 터널, 안쪽 전송, 안쪽 터널, 애플리케이션. 각 헤더를 한 번만 세고, UDP는 터널 자체의 헤더와 태그에서 분리해 두십시오.

WireGuard 계층 두 개, 한 번만 세기

IPv4 접속 경로에 WireGuard 터널 하나를 다른 터널 안에 넣는다고 합시다. 바깥 계층은 IPv4 20바이트, UDP 8바이트, WireGuard 데이터 헤더와 인증 태그에 32바이트를 씁니다. 그 안에서 안쪽 터널은 두 번째 32바이트 WireGuard 오버헤드 전에 자체 20바이트 IPv4 헤더와 8바이트 UDP 헤더가 필요합니다. 남는 부분에 IPv4 헤더, TCP 헤더, 데이터가 들어갑니다. 바깥 경로가 IPv6라면 20 대신 40을 쓰고 1320이 남습니다.

계산은 1340바이트에 이릅니다. 같은 규칙으로 계층 하나만 쓰면 TCP 페이로드에 1400이 남는데, 이는 1500에서 20, 8, 32, 20, 20을 뺀 값이고, 60바이트 차이는 두 번째 터널이 더하는 내부 캡슐화 그 자체입니다.

1400을 중첩 경로에 적용하면 안쪽 터널은 60바이트가 모자라고, 패킷이 그것을 필요로 할 만큼 커지기 전까지는 보이지 않습니다. 패딩과 프로토콜 자체의 단편화 옵션이 숫자를 다시 움직이므로 표를 믿으십시오.

MTU, MSS, 단편화는 서로 다른 곳에서 작동한다

인터페이스 MTU는 인터페이스가 내보낼 것을 제한하고, TCP MSS 클램핑은 TCP 상대가 보내려는 것을 바꿉니다. 클램핑은 TCP 세션을 고친다 그리고 큰 UDP 데이터그램에는 아무 일도 하지 않아서, 한 애플리케이션에서는 수정이 성공한 것처럼 보이고 다음 애플리케이션은 조용히 놓칩니다. 프로토콜 자체의 단편화 옵션은 나름의 실패를 지닌 세 번째 지렛대입니다. 인터페이스 MTU는 흔한 첫 조치이며 가장 거칩니다.

브리지 및 라우팅 터널은 서로 다른 프레임을 나르므로 다른 구축 환경의 숫자는 거의 적용되지 않습니다. 경로 MTU 검색은, RFC 8201에 설명되어 있으며, 그것이 의존하는 ICMP 메시지가 통과되는 동안에만 도움이 됩니다.

모자란 계층 찾기

요구 사항이 비교를 허용한다면 중첩하기 전에 각 터널을 따로 검증하십시오. 고정 크기 프로브가 그것을 판정합니다: ping -M do -s 1472 -c 3 10.8.0.1 그 계층 안에서 1500바이트 IPv4 패킷을 온전히 보냅니다. 두 번째 계층을 더하고 같은 프로브를 반복하면, 어떤 실패든 알려진 변경에 속하게 됩니다.

전송이 멈추면 문서화된 매개변수를 한 번에 하나씩 바꾸고 실패하는 크기를 기록하십시오. 중첩 경로 재귀가 패킷 크기 문제를 오후 하나를 잡아먹을 만큼 비슷하게 흉내 낼 수 있으므로 반환 경로도 확인하십시오. 필터링된 ICMP 응답은 실제 한계를 숨길 수 있으므로 추론보다 프로브가 더 중요합니다.

다음 사람이 찾을 수 있는 곳에 예산을 적어 두십시오

계층마다 한 행인 표는 경험칙보다 오래갑니다. 터널 다이어그램 옆에 두어 압박을 받을 때 아무도 계산을 다시 하지 않게 하십시오.

터널이 많을수록 의존성도 많아지므로 롤백 계획은 예산 옆에 설 자격이 있습니다. 숫자가 여전히 맞지 않으면 다시 추측하지 말고 경로를 측정하십시오. 목표는 기억하는 숫자가 아니라 변호할 수 있는 숫자입니다.