OpenVPN på PPPoE: senke link-mtu, tun-mtu eller mssfix?

Ping svarar, DNS slår opp, og kvar side som treng eit fullt segment, heng. På ei linje som legg til si eiga innkapsling, mistar ruta stille nokre dusin byte av budsjettet, og ein profil skriven for reint Ethernet held fram med å be om pakkar som linja ikkje kan bera. Sambandet er ikkje tregt; det kastar bort nettopp dei pakkane som betyr noko.

Tre alternativ kan retta dette, og dei verkar på ulike lag. Å velja feil gjer anten ingenting eller gjer tunnelen skjør på ein ny måte, så valet byrjar med kva ruta faktisk støttar.

Tre knappar, tre ulike lag

link-mtu er det ytre budsjettet: den krypterte nyttelasta pluss OpenVPN-hovudet, UDP-hovudet og det ytre IP-hovudet. Det skildrar kva som forlèt maskina, og difor er det talet den fysiske ruta avgrensar.

tun-mtu er det indre budsjettet: grensesnittet trafikken din ser. Det er nøyaktig tunnelens overhead større enn det ruta kan bera, og OpenVPN leier det vanlegvis ut i staden for å tvinga deg til å setja det.

mssfix er ein heilt annan mekanisme. Han skriv om den maksimale segmentstorleiken som vert annonsert under TCP-handtrykk, slik at TCP-partnarar vel segment som passar etter innkapslinga. Han endrar ikkje grensesnittet sin MTU, og har ingen effekt på UDP.

Viss du set link-mtu eksplisitt, trekkjer OpenVPN frå sin eigen overhead for å leia ut den indre MTU-en. Den overheaden er ikkje ein fast konstant; han avheng av chiffar og autentisering, og difor kan ein verdi kopiert frå eit forum vera feil på ein annan profil. Å setja både link-mtu og tun-mtu gir klienten to motstridande instruksjonar.

Mål ruta før du vel eit tal

Mål frå det fysiske grensesnittet, ikkje frå innsida av tunnelen, og hugs at ping rapporterer nyttelasta, ikkje pakkestorleiken. Legg til 28 byte for IPv4- og ICMP-hovuda før du samanliknar nyttelasta med ei ramme på 1500 byte, og ha den korreksjonen i tankane når ein part rapporterer eit anna tal.

På ein Linux-klient forbyr ping -M do -s 1472 fragmentering og feilar viss pakken er for stor. Senk nyttelasta til han går gjennom, og legg deretter til 28 for å få ruta sin MTU. PPPoE kostar 8 byte, så 1492 er normalt på DSL. DS-Lite og nokre mobile ruter kostar 40 eller meir, og svaret er vanlegvis lågare enn den nominelle linjehastigheita antydar.

Viss kvar ping-storleik lukkast, men store overføringar framleis heng, mistenk eit svart hol i staden for ei enkel storleiksgrense. Ei ICMP-melding om nødvendig fragmentering vert filtrert ein stad langs ruta, så avsendararen lærer aldri å krympa, og berre straumane som treng eit stort segment, merkar det.

Avgrens TCP først, krymp tunnelen etterpå

TCP-handtrykk er det einaste mssfix rører, noko som vanlegvis gjer det til den minst inngripande kontrollen å prøva først. Set han litt under det reelle budsjettet til ruta, send same verdi frå tenaren slik at begge endar er samde, og test ein stor nedlasting på nytt. Viss henginga forsvinn, var problemet TCP-segmentstorleiken, og ingenting anna treng å endrast.

Senk den indre MTU-en når trafikken som er råka, ikkje er TCP. Ein UDP-teneste, ein tunnel inne i tunnelen eller eit program som sender fullstore datagram vil halda fram med å feila etter ei MSS-avgrensing fordi ingenting skriv om pakkestorleiken. Reduser tun-mtu for det tilfellet, eller set link-mtu og la klienten leia ut den indre verdien, men aldri begge.

Ikkje grip etter det gamle fragmenteringsalternativet. Det delte pakkar inne i tunnelen, la til overhead og er avvikla av gode grunnar; moderne OpenVPN ventar at ruta vert skildra nøyaktig.

Kvifor små målingar held fram med å verka

DNS-spørjingar, ICMP-ekko og TCP-handtrykk ligg alle langt under storleiken som feilar. Tunnelen ser difor sunn ut i kvar rask test, medan TLS-handtrykk og HTTP-svar stille feilar. Nettopp den kombinasjonen, ein fungerande traceroute og ein nettlesar som heng på det første store svaret, er signalet du skal sjå etter. Grip etter ein full storleik test før du grip etter ein ny profil.

Stadfest med trafikken som feila. Hent ei stor side, send eit fullstort UDP-datagram viss det er tenesta som er råka, og gjer om frå ein annan klient på ei anna linje. Noter den målte ruta sin MTU og verdien du valde, for den neste som rører profilen vil elles handsama talet som vilkårleg.

Senk aldri den indre MTU-en under 1280 når IPv6 går over tunnelen, for det er minimumet kvar IPv6-lenke må bera. Ein mindre MTU er eit faktum om ruta, ikkje ei ytingsinnstilling å justera på kjensle.