OpenVPN mssfix: waarom één client vastloopt bij grote overdrachten

Eén laptop loopt vast bij uploads door de tunnel terwijl elk ander apparaat op dezelfde server blijft werken. Dat patroon wijst op één pad, niet op de serverconfiguratie, en het is de gebruikelijke ingang tot de mssfix-vraag. De optie kan helpen, maar alleen voor de TCP-verbindingen die hij echt herschrijft. De reikwijdte kennen voorkomt dat je een werkende server aanpast om één client te redden.

Wat de optie herschrijft

mssfix bewerkt de maximale segmentgrootte die wordt aangekondigd in TCP-handshakes die door de tunnel gaan, zodat de verzendende kant segmenten kiest die in het ingekapselde budget passen. Het werkt op de handshake, wat betekent dat een verbinding die vóór de wijziging is geopend de onderhandelde waarde behoudt.

Het verkleint geen UDP-datagrammen en het stelt de tunnel-MTU niet in. Twee verschillende problemen geven hetzelfde symptoom: een TCP-verzender die de padlimiet negeert, en een pad dat grote pakketten van elke grootte stil laat vallen. mssfix pakt het eerste aan en doet niets voor het tweede.

Dat onderscheid verklaart de teleurstellende experimenten. Een kleinere waarde op een pad met een zwart gat verandert de segmentgrootte, maar niet de drop die volgt, dus de overdracht mislukt op een ander punt.

Het bereik is TCP binnen de tunnel

Alleen TCP-verkeer wordt herschreven. Een QUIC-sessie, een game of een applicatie die grote UDP-datagrammen verstuurt, behoudt zijn eigen pakketgroottes, en als dat de overdrachten zijn die vastlopen, hoort de oplossing eerder bij de tunnel- of pad-MTU. Lees welk protocol de mislukkende overdracht gebruikt voordat je naar een TCP-optie grijpt, want de verkeerde laag heeft zijn eigen oplossing.

De richting is ook belangrijk. Een clientinstelling beïnvloedt het verkeer dat die client de tunnel in stuurt, terwijl de server de stromen dekt die hij naar clients doorstuurt. Als alleen inkomende downloads vastlopen, is de waarde aan de clientkant niet het hele verhaal.

Het getal en het sleutelwoord zijn niet overdraagbaar

De communityversie van OpenVPN 2.6 accepteert een optioneel sleutelwoord na de waarde. Met mtu beschrijft het getal de buitenste pakketgrootte inclusief IP- en UDP-headers; zonder volgt het argument een andere boekhoudconventie. Een regel die tussen versies wordt gekopieerd beschrijft dus niet hetzelfde pakketbudget. Raadpleeg de manualpagina die met de build meekomt die je echt draait, in plaats van een tutorial voor een andere release.

De syntaxis ziet er zo uit:

mssfix 1400 mtu

Behandel 1400 als een plaatshouder, niet als een aanbeveling voor jouw pad. Leid de waarde af uit het gemeten pad en de inkapseling die echt wordt gebruikt, en onthoud dat clients op oudere versies of andere implementaties het sleutelwoord kunnen weigeren of anders interpreteren.

Bevestig het eerst op de ene client

Meet het pad vanaf de falende machine voordat je iets verandert. Een payload die het pad zonder fragmentatie kan dragen, is het getal dat je zoekt:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

De eerste test past in een pakket van 1500 bytes zodra de 28 bytes headers erbij komen. Als hij faalt met een fragmentatiefout en de kleinere slaagt, ligt de bruikbare grootte ergens daartussen, en de tunneloverhead gaat er van boven af.

Herhaal daarna de overdracht die vastliep, op een nieuwe verbinding, en vergelijk. Als de ene client verbetert terwijl de andere onaangeroerd blijven, heb je de reikwijdte van het probleem gevonden. Als elke client vastloopt, is de waarde aan de serverkant degene die je moet herzien. Geen van beide resultaten rechtvaardigt een wijziging op hardware die nooit in het falende pad zat.