Waarom OpenConnect-pagina’s blijven hangen tot je de MTU van de tunnel verlaagt

Inloggen lukt, de voorpagina van het portaal wordt getekend, en dan blijft een dashboardwidget of een rapport op waiting for host staan tot de browser het opgeeft. Openbare sites laden de hele tijd normaal, en er is geen inloggegeven veranderd. Dat kleine antwoorden aankomen terwijl grote vastlopen, is het kenmerk van een plafond op de pakketgrootte en niet van een toegangsregel. Bevestig die lezing voordat je iets anders in het profiel wijzigt.

Scheid een groottprobleem van een beleidsprobleem

Begin met een weigering uit te sluiten. Als de gateway je had geweigerd, zou de verbinding meteen zijn mislukt in plaats van een pagina half te laden. Een tunnel die opkomt en daarna alleen bij grotere overdrachten vastloopt, vertelt je dat het buitenste pad het binnenste pakket niet kan dragen.

Het mechanisme is inkapseling. Elk binnenste pakket krijgt tunnelheaders, zodat een payload die in de fysieke link paste een buitenste pakket wordt dat er niet meer in past, en alles wat de do-not-fragment-bit draagt, wordt weggegooid zonder antwoord dat de browser kan interpreteren.

Meet het plafond met do-not-fragment-probes

Meet het plafond in plaats van het te gokken. Stuur probes die fragmentatie weigeren en verlaag de payload stap voor stap tot er een antwoord terugkomt, te beginnen met een opdracht zoals ping -M do -s 1472 host. Een antwoord dat klaagt dat fragmentatie nodig is terwijl DF is ingesteld, betekent dat de waarde nog te hoog is. Herhaal op 1462, dan 1452, en stop bij de eerste grootte die antwoordt. Noteer het getal samen met de host die je hebt getest, want het antwoord hoort bij dat pad en niet bij het protocol in het algemeen.

Test het adres waar de tunnel echt verkeer naartoe stuurt. Een buitenste probe tegen de openbare naam van de gateway en een binnenste probe tegen een interne server meten verschillende hops, en ICMP-filtering op een van beide kan een gezond pad kapot laten lijken.

Pas de waarde toe op het tunnelapparaat

Pas het resultaat toe op de interface die de client heeft gemaakt, niet op de wifi-adapter. Op een Linux-client is dat ip link set dev tun0 mtu 1300 gevolgd door ip link show tun0 om te bevestigen dat de waarde is overgenomen. Gebruik de apparaatnaam die de client meldt, want die verschilt per implementatie en per hoe de tunnel is gebouwd.

De MTU van de tunnel verlagen verkleint de payload die elk pakket draagt, dus de bulkdoorvoer daalt een beetje, en dat is de prijs om grote antwoorden niet in een zwart gat te gooien. Een kleiner getal is niet automatisch veiliger. De fysieke adapter aanpassen in plaats daarvan verdeelt de schade over elke verbinding op die link, terwijl te grote binnenste pakketten net zo groot blijven.

Gebruik eerst de MTU-verzoeken van de client zelf

Wanneer je de aanroep beheert, kan de client om een grootte vragen in plaats van achteraf gepatcht te worden. --mtu vraagt de server om een tunnel-MTU, en --base-mtu verklaart de MTU van het onderliggende pad zodat de gateway het tunnelgetal kan afleiden. Beide zijn verzoeken, en de handleiding van de client belooft niet dat de gateway een van beide honoreert.

Dat onderscheid bepaalt je werkvolgorde. Probeer eerst het verzoek en inspecteer de interface die het oplevert, en val dan terug op het lokaal instellen van het apparaat als de waarde die de gateway koos nog steeds vastloopt.

Verifieer met de overdracht die mislukte, en maak het dan blijvend

Een lokale ip link-wijziging houdt stand tot de client de tunnel opnieuw opbouwt, wat bij de volgende herverbinding of hervatting gebeurt. Zet de waarde waar de verbinding begint: een wrapper die de client start en daarna het apparaat aanpast, een systemd-unit met een ExecStartPost-stap, of de clientoptie wanneer de gateway die accepteert. Houd hem naast het profiel in versiebeheer zodat de volgende persoon ziet waarom het getal er staat.

Test met het verzoek dat mislukte, niet met de voorpagina. Open het rapport, haal de bijlage op, of voer de repository-fetch uit die bleef hangen, en noteer precies waar het stopt als het nog steeds stopt. Een pagina die na de wijziging wordt getekend, bewijst weinig, want die werd ervoor ook getekend.

Als dezelfde overdracht op hetzelfde punt vastloopt, is de MTU-theorie onbewezen. Leg verkeer op de tunnel vast en controleer welke kant stopt met zenden voordat je het getal weer wijzigt, en houd de vorige waarde genoteerd zodat een terugdraaiing een opdracht blijft.