OpenVPN op PPPoE: link-mtu, tun-mtu of mssfix verlagen?

Pings antwoorden, DNS lost op, en elke pagina die een volledig segment nodig heeft, blijft hangen. Op een uplink die zijn eigen inkapseling toevoegt, verliest het pad stil een paar dozijn bytes budget, en een profiel dat voor schoon Ethernet is geschreven, blijft pakketten vragen die de lijn niet kan dragen. De verbinding is niet traag; hij gooit precies de pakketten weg die ertoe doen.

Drie opties kunnen dit oplossen, en ze werken op verschillende lagen. De verkeerde kiezen doet ofwel niets of maakt de tunnel op een nieuwe manier kwetsbaar, dus de keuze begint bij wat het pad werkelijk ondersteunt.

Drie knoppen, drie verschillende lagen

link-mtu is het buitenste budget: de versleutelde payload plus de OpenVPN-header, de UDP-header en de buitenste IP-header. Het beschrijft wat de machine verlaat, en daarom is het het getal dat het fysieke pad beperkt.

tun-mtu is het binnenste budget: de interface die uw verkeer ziet. Het is precies de overhead van de tunnel groter dan wat het pad kan dragen, en OpenVPN leidt het meestal af in plaats van u het te laten instellen.

mssfix is een volledig ander mechanisme. Het herschrijft de maximale segmentgrootte die tijdens TCP-handshakes wordt aangekondigd, zodat TCP-peers segmenten kiezen die na de inkapseling passen. Het verandert de MTU van de interface niet, en het heeft geen effect op UDP.

Als u link-mtu expliciet instelt, trekt OpenVPN zijn eigen overhead ervan af om de binnenste MTU af te leiden. Die overhead is geen vaste constante; hij hangt af van het cijfer en de authenticatie, en daarom kan een van een forum gekopieerde waarde op een ander profiel onjuist zijn. Zowel link-mtu als tun-mtu instellen geeft de client twee tegenstrijdige instructies.

Meet het pad voordat u een getal kiest

Meet vanaf de fysieke interface, niet van binnen de tunnel, en onthoud dat ping de payload rapporteert, niet de pakketgrootte. Tel 28 bytes op voor de IPv4- en ICMP-headers voordat u de payload met een frame van 1500 bytes vergelijkt, en houd die correctie in gedachten wanneer een peer een ander getal rapporteert.

Op een Linux-client verbiedt ping -M do -s 1472 fragmentatie en mislukt als het pakket te groot is. Verlaag de payload tot het doorkomt, en tel er dan 28 bij op om de MTU van het pad te krijgen. PPPoE kost 8 bytes, dus 1492 is normaal op DSL. DS-Lite en sommige mobiele paden kosten 40 of meer, en het antwoord ligt meestal lager dan de nominale linksnelheid suggereert.

Als elke pinggrootte slaagt maar grote overdrachten nog steeds hangen, verdenk dan een zwart gat in plaats van een simpele groottelimiet. Een ICMP-bericht over benodigde fragmentatie wordt ergens langs het pad gefilterd, dus de afzender leert nooit om te krimpen, en alleen de stromen die een groot segment nodig hebben, merken het.

Beperk eerst TCP, krimp daarna de tunnel

TCP-handshakes zijn het enige dat mssfix aanraakt, waardoor het meestal de minst ingrijpende controle is om eerst te proberen. Zet het iets onder het werkelijke budget van het pad, stuur dezelfde waarde vanaf de server zodat beide uiteinden het eens zijn, en test opnieuw een grote download. Als de hang verdwijnt, was het probleem de TCP-segmentgrootte, en hoeft er niets anders te veranderen.

Verlaag de binnenste MTU wanneer het getroffen verkeer geen TCP is. Een UDP-dienst, een tunnel in de tunnel of een toepassing die datagrammen van volledige grootte verstuurt, blijft falen na een MSS-beperking omdat niets de pakketgrootte herschrijft. Verlaag tun-mtu voor dat geval, of stel link-mtu in en laat de client de binnenste waarde afleiden, maar nooit beide.

Grijp niet naar de oude fragmentatieoptie. Die splitste pakketten binnen de tunnel, voegde overhead toe en is om goede redenen verouderd; moderne OpenVPN verwacht dat het pad nauwkeurig wordt beschreven.

Waarom kleine probes blijven werken

DNS-query’s, ICMP-echo’s en TCP-handshakes liggen allemaal ver onder de grootte die faalt. De tunnel lijkt daardoor gezond in elke snelle test, terwijl TLS-handshakes en HTTP-responses stil falen. Precies die combinatie, een werkende traceroute en een browser die bij het eerste grote antwoord blijft hangen, is het signaal waarnaar u moet zoeken. Grijp naar een probe van volledige grootte voordat u naar een nieuw profiel grijpt.

Controleer met het verkeer dat faalde. Haal een grote pagina op, stuur een UDP-datagram van volledige grootte als dat de getroffen dienst is, en herhaal vanaf een tweede client op een andere uplink. Noteer de gemeten MTU van het pad en de waarde die u koos, want de volgende persoon die het profiel aanraakt, beschouwt het getal anders als willekeurig.

Breng de binnenste MTU nooit onder 1280 wanneer IPv6 over de tunnel loopt, want dat is het minimum dat elke IPv6-verbinding moet dragen. Een kleinere MTU is een feit over het pad, geen prestatie-instelling om op gevoel af te stemmen.