Waarom een VPN bij grote overdrachten blijft hangen en bij kleine niet

Een pagina laadt, een ping slaagt en een bestandskopie blijft elke keer op hetzelfde punt hangen. Dat patroon wijst op pakketgrootte, niet op bandbreedte of inloggegevens. Encapsulatie voegt bytes toe aan elk pakket, dus een payload die op het oorspronkelijke pad paste, kan de limiet overschrijden zodra hij door een tunnel gaat. In deze gesprekken worden drie verschillende getallen MTU genoemd, en verwarring daarvan leidt tot een instelling die de ene toepassing repareert en de andere breekt.

Drie getallen die mensen MTU noemen

De interface-MTU is de geconfigureerde limiet voor een pakket op die verbinding. De pad-MTU is de kleinste limiet langs de route, en die wordt ontdekt in plaats van geconfigureerd. De TCP MSS is de payloadgrootte die een peer opgeeft te kunnen ontvangen, en die is afgeleid van de andere twee in plaats van een aparte fysieke limiet.

Een tunnel heeft een binnen- en een buitenbeeld. Het buitenste pakket draagt het ingekapselde pakket plus de headers die het protocol nodig heeft, dus de bruikbare binnenmaat is kleiner dan het buitenste pad toestaat. Het pad naar de VPN-server verschilt ook van het pad van de server naar de bestemming.

Pad-MTU-ontdekking laat een afzender de werkende grootte leren, maar het hangt ervan af of feedback aankomt. Wanneer een tussenliggend apparaat de relevante ICMP-berichten filtert, blijft de afzender pakketten sturen die nooit voltooien, en dat is het klassieke zwarte gat. Het symptoom is kenmerkend als je het kent: de handshake slaagt, de eerste payload op volle grootte verdwijnt en de verbinding wordt uiteindelijk gereset of blijft hangen. Niets in het log van de toepassing ziet eruit als een netwerkprobleem.

Onderzoek het pad met een payload die je beheert

Een test is bewijs over één route en één grootte, geen aanbevolen instelling. Gebruik een host die antwoordt, en varieer alleen de grootte van de payload.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

De eerste opdracht stuurt een Linux-test met fragmentatie uitgeschakeld en een payload van 1372 bytes, en de tweede doet hetzelfde op Windows waar de payload met -l wordt ingesteld. Een antwoord betekent dat die grootte het pad heeft overleefd. Een melding dat fragmentatie nodig is, is informatief, terwijl een time-out dubbelzinnig is omdat de host of een tussenliggend apparaat ICMP gewoon kan laten vallen.

Ga de grootte in een paar stappen naar beneden in plaats van binair tot op de byte te zoeken. Je probeert vast te stellen of er een grootteplafond bestaat, niet om een getal voor elk netwerk te publiceren. Het getal dat je vindt, geldt voor dit pad, dit protocol en deze adresfamilie.

IPv4 en IPv6 fragmenteren anders, dus een testresultaat van de ene familie zegt niets over de andere. Test de familie die de toepassing werkelijk gebruikt.

MSS-clamping helpt alleen TCP

Bij TCP wordt de effectieve payload tijdens de handshake onderhandeld, en een router op het pad kan die waarde naar beneden herschrijven zodat beide uiteinden kleinere segmenten sturen. Dat is wat MSS-clamping doet, en het werkt zonder de client überhaupt aan te raken.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

De eerste regel klemt de aangekondigde MSS naar de pad-MTU voor doorgestuurde TCP-handshakes, en de tweede toont de eigen MTU van de tunnelinterface zodat je die kunt vergelijken met wat het pad toestaat. Clamping is de minst ingrijpende reparatie voor een TCP-toepassing die na de handshake blijft hangen.

Voor UDP doet het niets. Een spraak- of gameclient die grote datagrammen stuurt, negeert een MSS-instelling volledig, omdat er geen handshake is om te herschrijven. Als de falende toepassing UDP is, kijk dan in plaats daarvan naar de pakketgrootte-opties van de client zelf. De twee protocollen falen anders en worden met andere gereedschappen gerepareerd, daarom hoort het protocol in de eerste zin van het ticket.

OpenVPN biedt opties zoals tun-mtu, mssfix en fragmentatiegerelateerde instellingen, en hun gedrag hangt af van de versie en van of het datakanaal AEAD is. Lees de handleiding voor de gebruikte versie, en wijzig één optie per keer.

Wijzig één ondersteunde instelling en herhaal beide runs

Houd het oorspronkelijke profiel, wijzig één ondersteunde waarde, en herhaal zowel het kleine verzoek dat werkte als de grote overdracht die faalde. Als alleen de grote verandert, zat je achter grootte aan. Als beide veranderen, is er iets anders mee bewogen.

Een lagere waarde kan het symptoom verminderen terwijl hij overhead toevoegt, dus het kleinst mogelijke getal is niet het doel. Het doel is een grootte die het pad betrouwbaar draagt met zo weinig mogelijk verspilling. Noteer de waarde, het pad en de clientversie in het ticket, want hetzelfde getal elders toepassen is een gok.

Als hetzelfde profiel vanaf een ander vertrouwd netwerk werkt, houd dat verschil dan in de diagnose in plaats van de client als gerepareerd te verklaren. De variabele die veranderde is het pad, en het pad is wat de test heeft gemeten.