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

Ping svarer, DNS slår opp, og hver side som trenger et fullt segment, henger. På en linje som legger til sin egen innkapsling, mister ruten stille noen dusin byte av budsjettet, og en profil skrevet for rent Ethernet fortsetter å be om pakker som linjen ikke kan bære. Forbindelsen er ikke treg; den kaster bort nøyaktig de pakkene som betyr noe.

Tre alternativer kan rette dette, og de virker på forskjellige lag. Å velge feil gjør enten ingenting eller gjør tunnelen skjør på en ny måte, så valget begynner med hva ruten faktisk støtter.

Tre knapper, tre forskjellige lag

link-mtu er det ytre budsjettet: den krypterte nyttelasten pluss OpenVPN-headeren, UDP-headeren og den ytre IP-headeren. Det beskriver hva som forlater maskinen, og derfor er det tallet den fysiske ruten begrenser.

tun-mtu er det indre budsjettet: grensesnittet trafikken din ser. Det er nøyaktig tunnelens overhead større enn det ruten kan bære, og OpenVPN utleder det vanligvis i stedet for å tvinge deg til å sette det.

mssfix er en helt annen mekanisme. Den skriver om den maksimale segmentstørrelsen som annonseres under TCP-håndtrykk, slik at TCP-partnere velger segmenter som passer etter innkapslingen. Den endrer ikke grensesnittets MTU, og har ingen effekt på UDP.

Hvis du setter link-mtu eksplisitt, trekker OpenVPN fra sin egen overhead for å utlede den indre MTU. Den overheaden er ikke en fast konstant; den avhenger av chiffer og autentisering, og derfor kan en verdi kopiert fra et forum være feil på en annen profil. Å sette både link-mtu og tun-mtu gir klienten to motstridende instruksjoner.

Mål ruten før du velger et tall

Mål fra det fysiske grensesnittet, ikke fra innsiden av tunnelen, og husk at ping rapporterer nyttelasten, ikke pakkestørrelsen. Legg til 28 byte for IPv4- og ICMP-headerne før du sammenligner nyttelasten med en ramme på 1500 byte, og ha den korreksjonen i tankene når en part rapporterer et annet tall.

På en Linux-klient forbyr ping -M do -s 1472 fragmentering og feiler hvis pakken er for stor. Senk nyttelasten til den går gjennom, og legg deretter til 28 for å få rutens MTU. PPPoE koster 8 byte, så 1492 er normalt på DSL. DS-Lite og noen mobile ruter koster 40 eller mer, og svaret er vanligvis lavere enn den nominelle linjehastigheten antyder.

Hvis hver ping-størrelse lykkes, men store overføringer fortsatt henger, mistenker du et svart hull i stedet for en enkel størrelsesgrense. En ICMP-melding om nødvendig fragmentering blir filtrert et sted langs ruten, så avsenderen lærer aldri å krympe, og bare strømmene som trenger et stort segment, merker det.

Begrens TCP først, krymp tunnelen etterpå

TCP-håndtrykk er det eneste mssfix berører, noe som vanligvis gjør det til den minst inngripende kontrollen å prøve først. Sett den litt under rutens reelle budsjett, send samme verdi fra serveren slik at begge ender er enige, og test en stor nedlasting på nytt. Hvis hengingen forsvinner, var problemet TCP-segmentstørrelsen, og ingenting annet trenger å endres.

Senk den indre MTU når trafikken som er berørt, ikke er TCP. En UDP-tjeneste, en tunnel inne i tunnelen eller et program som sender fullstore datagrammer vil fortsette å feile etter en MSS-begrensning fordi ingenting skriver om pakkestørrelsen. Reduser tun-mtu for det tilfellet, eller sett link-mtu og la klienten utlede den indre verdien, men aldri begge.

Ikke grip etter det gamle fragmenteringsalternativet. Det delte pakker inne i tunnelen, la til overhead og er avviklet av gode grunner; moderne OpenVPN forventer at ruten beskrives nøyaktig.

Hvorfor små målinger fortsetter å virke

DNS-spørringer, ICMP-ekkoer og TCP-håndtrykk ligger alle langt under størrelsen som feiler. Tunnelen ser derfor sunn ut i hver rask test, mens TLS-håndtrykk og HTTP-svar stille feiler. Nettopp den kombinasjonen, en fungerende traceroute og en nettleser som henger på det første store svaret, er signalet du skal se etter. Grip etter en full størrelse test før du griper etter en ny profil.

Bekreft med trafikken som feilet. Hent en stor side, send et fullstort UDP-datagram hvis det er tjenesten som er berørt, og gjenta fra en annen klient på en annen linje. Noter den målte rutens MTU og verdien du valgte, for den neste som berører profilen vil ellers behandle tallet som vilkårlig.

Senk aldri den indre MTU under 1280 når IPv6 går over tunnelen, for det er minimumet hver IPv6-lenke må bære. En mindre MTU er et faktum om ruten, ikke en ytelsesinnstilling å justere på følelse.