PPPoE에서의 OpenVPN: link-mtu, tun-mtu, mssfix 중 무엇을 줄일까?

핑은 응답하고 DNS는 해석되지만, 가득 찬 세그먼트가 필요한 페이지는 모두 멈춘다. 자체 캡슐화를 더하는 업링크에서는 경로가 조용히 수십 바이트의 예산을 잃고, 깨끗한 이더넷용으로 작성된 프로필은 회선이 실어 나를 수 없는 패킷을 계속 요구한다. 연결이 느린 것이 아니라, 중요한 패킷만 정확히 버리고 있는 것이다.

세 가지 선택지가 이를 고칠 수 있고, 각각 다른 계층에서 작동한다. 잘못 고르면 아무 효과가 없거나 터널이 새롭게 취약해지므로, 선택은 경로가 실제로 지원하는 것에서 시작된다.

세 개의 손잡이, 세 개의 계층

link-mtu는 바깥 예산, 즉 암호화된 페이로드에 OpenVPN 헤더, UDP 헤더, 바깥 IP 헤더를 더한 값이다. 머신을 떠나는 것을 기술하므로, 물리적 경로가 제한하는 숫자가 바로 이것이다.

tun-mtu는 안쪽 예산, 즉 트래픽이 보는 인터페이스다. 경로가 실을 수 있는 것보다 정확히 터널 오버헤드만큼 크며, OpenVPN은 보통 사용자가 설정하게 하는 대신 이를 도출한다.

mssfix는 전혀 다른 메커니즘이다. TCP 핸드셰이크 중에 알려지는 최대 세그먼트 크기를 다시 써서, TCP 상대가 캡슐화 후에도 들어맞는 세그먼트를 고르게 한다. 인터페이스 MTU를 바꾸지 않고, UDP에는 아무 효과가 없다.

link-mtu를 명시적으로 설정하면 OpenVPN은 안쪽 MTU를 도출하기 위해 자체 오버헤드를 뺀다. 그 오버헤드는 고정 상수가 아니며 암호와 인증에 따라 다르므로, 포럼에서 복사한 값이 다른 프로필에서는 틀릴 수 있다. link-mtu와 tun-mtu를 함께 설정하면 클라이언트에 모순된 두 지시를 주는 셈이다.

어떤 숫자를 고르기 전에 경로를 측정하라

터널 안이 아니라 물리 인터페이스에서 측정하고, 핑이 보고하는 것은 페이로드이지 패킷 크기가 아님을 기억하라. 페이로드를 1500바이트 프레임과 비교하기 전에 IPv4와 ICMP 헤더 몫으로 28바이트를 더하고, 상대가 다른 숫자를 보고할 때 그 보정을 염두에 두라.

Linux 클라이언트에서 ping -M do -s 1472는 단편화를 금지하며 패킷이 너무 크면 실패한다. 통과할 때까지 페이로드를 낮춘 다음 28을 더해 경로 MTU를 구하라. PPPoE는 8바이트를 쓰므로 DSL에서 1492가 정상이다. DS-Lite와 일부 모바일 경로는 40 이상을 쓰며, 답은 대개 명목 링크 속도가 시사하는 것보다 낮다.

모든 핑 크기가 성공하는데도 큰 전송이 계속 멈춘다면 단순한 크기 한계가 아니라 블랙홀을 의심하라. 단편화가 필요하다는 ICMP 메시지가 경로 어딘가에서 필터링되어, 송신자는 줄이는 법을 배우지 못하고 큰 세그먼트가 필요한 흐름만 이를 알아챈다.

먼저 TCP를 제한하고, 그다음 터널을 줄여라

TCP 핸드셰이크만이 mssfix가 건드리는 대상이므로, 보통 가장 덜 방해되는 제어로 먼저 시도하게 된다. 경로의 실제 예산보다 조금 낮게 설정하고, 양쪽 끝이 합의하도록 서버에서도 같은 값을 보내고, 큰 다운로드를 다시 시험하라. 멈춤이 사라지면 문제는 TCP 세그먼트 크기였고, 다른 것은 바꿀 필요가 없다.

영향받는 트래픽이 TCP가 아닐 때는 안쪽 MTU를 낮춰라. UDP 서비스, 터널 속의 터널, 또는 가득 찬 크기의 데이터그램을 보내는 애플리케이션은 패킷 크기를 다시 쓰는 것이 없기 때문에 MSS 제한 후에도 계속 실패한다. 그런 경우에는 tun-mtu를 줄이거나, link-mtu를 설정하고 클라이언트가 안쪽 값을 도출하게 하되, 둘 다는 절대 하지 말 것.

옛 단편화 옵션에 손을 대지 마라. 터널 안에서 패킷을 쪼개고 오버헤드를 더한 탓에 타당한 이유로 폐기되었으며, 현대의 OpenVPN은 대신 경로를 정확히 기술하기를 기대한다.

작은 측정이 계속 통하는 이유

DNS 질의, ICMP 에코, TCP 핸드셰이크는 모두 실패하는 크기보다 훨씬 작다. 그래서 터널은 모든 빠른 시험에서 건강해 보이지만 TLS 핸드셰이크와 HTTP 응답은 조용히 실패한다. 동작하는 traceroute와 첫 큰 응답에서 멈추는 브라우저라는 이 조합이 찾아야 할 징후다. 새 프로필에 손을 대기 전에 가득 찬 크기의 시험에 손을 대라.

실패했던 트래픽으로 확인하라. 큰 페이지를 가져오고, 영향받는 서비스가 그것이라면 가득 찬 크기의 UDP 데이터그램을 보내고, 다른 업링크의 두 번째 클라이언트에서 반복하라. 프로필을 만지게 될 다음 사람이 그 숫자를 임의로 여기지 않도록, 측정한 경로 MTU와 선택한 값을 기록하라.

IPv6가 터널 위로 돌 때는 모든 IPv6 링크가 실어야 하는 최솟값인 1280 아래로 안쪽 MTU를 내리지 마라. 더 작은 MTU는 경로에 관한 사실이지, 느낌으로 조정하는 성능 설정이 아니다.