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

Pings antwoord, DNS los op, en elke bladsy wat ’n volgrootte-segment nodig het, hang. Op ’n oplynverbinding wat sy eie inkapseling byvoeg, verloor die pad stilweg ’n paar dosyn grepe begroting, en ’n profiel wat vir skoon Ethernet geskryf is, bly vra vir pakkette wat die lyn nie kan dra nie. Die verbinding is nie stadig nie; dit gooi juis die pakkette weg wat saak maak.

Drie opsies kan dit regstel, en hulle werk op verskillende vlakke. Om die verkeerde een te kies doen óf niks óf maak die tonnel op ’n nuwe manier broos, so die keuse begin by wat die pad werklik ondersteun.

Drie knoppies, drie verskillende vlakke

link-mtu is die buitenste begroting: die versleutelde loonvrag plus die OpenVPN-opskrif, die UDP-opskrif en die buitenste IP-opskrif. Dit beskryf wat die masjien verlaat, en daarom is dit die getal wat die fisiese pad beperk.

tun-mtu is die binnerste begroting: die koppelvlak wat jou verkeer sien. Dit is presies die tonnel-oorhoofd groter as wat die pad kan dra, en OpenVPN lei dit gewoonlik af eerder as om jou dit te laat stel.

mssfix is heeltemal ’n ander meganisme. Dit herskryf die maksimum segmentgrootte wat tydens TCP-handdrukke aangekondig word, sodat TCP-evene grootte kies wat ná inkapseling pas. Dit verander nie die koppelvlak-MTU nie, en dit het geen uitwerking op UDP nie.

As jy link-mtu eksplisiet stel, trek OpenVPN sy eie oorhoofd af om die binnerste MTU af te lei. Daardie oorhoofd is nie ’n vaste konstante nie; dit hang af van die syfer en verifikasie, en daarom kan ’n waarde wat uit ’n forumpos gekopieer is op ’n ander profiel verkeerd wees. Om beide link-mtu en tun-mtu te stel, gee die kliënt twee teenstrydige opdragte.

Meet die pad voordat jy enige getal kies

Meet vanaf die fisiese koppelvlak, nie van binne die tonnel nie, en onthou dat ping die loonvrag rapporteer, nie die pakketgrootte nie. Tel 28 grepe by vir die IPv4- en ICMP-opskrifte voordat jy die loonvrag met ’n raam van 1500 grepe vergelyk, en hou daardie regstelling in gedagte wanneer ’n eweknie ’n ander getal rapporteer.

Op ’n Linux-kliënt verbied ping -M do -s 1472 fragmentering en misluk dit as die pakket te groot is. Verlaag die loonvrag totdat dit deurkom, en tel dan 28 by om die pad-MTU te kry. PPPoE kos 8 grepe, so 1492 is normaal op DSL. DS-Lite en sommige mobiele paaie kos 40 of meer, en die antwoord is gewoonlik laer as wat die nominale skakelspoed voorstel.

As elke ping-grootte slaag maar groot oordragte steeds hang, vermoed ’n swart gat eerder as ’n eenvoudige groottelimiet. ’n ICMP-fragmentasie-benodig-boodskap word iewers langs die pad gefiltreer, so die sender leer nooit om te krimp nie, en net die strome wat ’n groot segment nodig het, merk dit.

Knyp TCP eers, krimp die tonnel tweede

TCP-handdrukke is die enigste ding wat mssfix raak, wat dit gewoonlik die minste ontwrigtende beheer maak om eerste te probeer. Stel dit ’n bietjie onder die pad se werklike begroting, stuur dieselfde waarde van die bediener af sodat beide kante saamstem, en toets weer ’n groot aflaai. As die hang opklaar, was die probleem TCP-segmentgrootte, en niks anders hoef te verander nie.

Verlaag die binnerste MTU wanneer die betrokke verkeer nie TCP is nie. ’n UDP-diens, ’n tonnel binne die tonnel, of ’n toepassing wat volgrootte-datagramme stuur, sal bly misluk ná ’n MSS-knyp omdat niks sy pakketgrootte herskryf nie. Verminder tun-mtu vir daardie geval, of stel link-mtu en laat die kliënt die binnerste waarde aflei, maar nooit beide nie.

Moenie na die ou fragmenteringsopsie gryp nie. Dit het pakkette binne die tonnel opgesplit, oorhoofd bygevoeg en is om goeie redes uitgefaseer; moderne OpenVPN verwag eerder dat die pad akkuraat beskryf word.

Waarom klein peilings aanhou werk

DNS-navrae, ICMP-eggo’s en TCP-handdrukke is almal ver onder die mislukkende grootte. Die tonnel lyk dus gesond in elke vinnige toets terwyl TLS-handdrukke en HTTP-antwoorde stilweg misluk. Daardie kombinasie, ’n werkende traceroute en ’n blaaier wat by die eerste groot antwoord hang, is die kenmerk om na te soek. Gryp na ’n volgrootte-peiling voordat jy na ’n nuwe profiel gryp.

Verifieer met die verkeer wat misluk het. Haal ’n groot bladsy, stuur ’n volgrootte UDP-datagram as dit die betrokke diens is, en herhaal dit vanaf ’n tweede kliënt op ’n ander oplynverbinding. Teken die gemete pad-MTU en die waarde wat jy gekies het aan, want die volgende persoon wat aan die profiel raak, sal die getal andersins as willekeurig beskou.

Moet nooit die binnerste MTU onder 1280 laat sak wanneer IPv6 oor die tonnel loop nie, want dit is die minimum wat elke IPv6-skakel moet dra. ’n Kleiner MTU is ’n feit oor die pad, nie ’n prestasie-instelling om op gevoel te stel nie.