OpenVPN på PPPoE: sænk link-mtu, tun-mtu eller mssfix?

Ping svarer, DNS slår op, og hver side, der kræver et fuldt segment, går i stå. På en forbindelse, der selv lægger indkapsling oveni, taber ruten lydløst nogle få dusin bytes af budgettet, og en profil skrevet til rent Ethernet bliver ved med at bede om pakker, som linjen ikke kan bære. Forbindelsen er ikke langsom; den kasserer præcis de pakker, der betyder noget.

Tre muligheder kan løse dette, og de virker på forskellige lag. Vælger du den forkerte, gør den enten ingenting eller gør tunnelen skrøbelig på en ny måde, så valget starter med, hvad ruten faktisk understøtter.

Tre knapper, tre forskellige lag

link-mtu er det ydre budget: den krypterede nyttelast plus OpenVPN-headeren, UDP-headeren og den ydre IP-header. Den beskriver, hvad der forlader maskinen, og det er derfor, det er det tal, den fysiske rute begrænser.

tun-mtu er det indre budget: det interface, din trafik ser. Det er større end det, ruten kan bære, med præcis tunnelens overhead, og OpenVPN udleder det normalt i stedet for at kræve, at du angiver det.

mssfix er en helt anden mekanisme. Den omskriver den maksimale segmentstørrelse, der annonceres under TCP-handshakes, så TCP-partnere vælger segmenter, der passer efter indkapslingen. Den ændrer ikke interfacets MTU og har ingen effekt på UDP.

Hvis du angiver link-mtu eksplicit, trækker OpenVPN sit eget overhead fra for at udlede den indre MTU. Det overhead er ikke en fast konstant; det afhænger af cipher og autentificering, og derfor kan en værdi kopieret fra et forumindlæg være forkert på en anden profil. Angiver du både link-mtu og tun-mtu, giver du klienten to modstridende instruktioner.

Mål ruten, før du vælger et tal

Mål fra det fysiske interface, ikke inde fra tunnelen, og husk, at ping rapporterer nyttelast, ikke pakkestørrelse. Læg 28 bytes til for IPv4- og ICMP-headerne, før du sammenligner nyttelasten med en ramme på 1500 bytes, og husk den korrektion, når en peer rapporterer et andet tal.

På en Linux-klient forbyder ping -M do -s 1472 fragmentering og fejler, hvis pakken er for stor. Sænk nyttelasten, til den går igennem, og læg derefter 28 til for at få rutens MTU. PPPoE koster 8 bytes, så 1492 er normalt på DSL. DS-Lite og nogle mobile ruter koster 40 eller mere, og svaret er normalt lavere, end den nominelle linkhastighed antyder.

Hvis hver ping-størrelse lykkes, men store overførsler stadig går i stå, skal du mistænke et sort hul frem for en simpel størrelsesgrænse. En ICMP-meddelelse om nødvendig fragmentering bliver filtreret et sted på ruten, så afsenderen lærer aldrig at skrumpe, og kun de flows, der har brug for et stort segment, bemærker det.

Begræns TCP først, skrump tunnelen bagefter

TCP-handshakes er det eneste, mssfix rører, og derfor er den normalt den mindst indgribende kontrol at prøve først. Sæt den lidt under rutens reelle budget, send samme værdi fra serveren, så begge ender er enige, og test en stor download igen. Forsvinder problemet, var årsagen TCP-segmentstørrelsen, og intet andet behøver at ændres.

Sænk den indre MTU, når den berørte trafik ikke er TCP. En UDP-tjeneste, en tunnel inde i tunnelen eller et program, der sender datagrammer i fuld størrelse, vil fortsætte med at fejle efter en MSS-begrænsning, fordi intet omskriver dens pakkestørrelse. Sænk tun-mtu i det tilfælde, eller angiv link-mtu og lad klienten udlede den indre værdi, men aldrig begge.

Grib ikke efter den gamle fragmenteringsindstilling. Den delte pakker inde i tunnelen, gav ekstra overhead og er blevet forældet med god grund; moderne OpenVPN forventer i stedet, at ruten beskrives præcist.

Hvorfor små prober bliver ved med at virke

DNS-forespørgsler, ICMP-ekkoer og TCP-handshakes ligger alle langt under den størrelse, der fejler. Tunnelen ser derfor sund ud i enhver hurtig test, mens TLS-handshakes og HTTP-svar lydløst fejler. Netop den kombination, en fungerende traceroute og en browser, der går i stå på det første store svar, er det fingerpeg, du skal lede efter. Tag en probe i fuld størrelse frem, før du tager en ny profil frem.

Bekræft med den trafik, der fejlede. Hent en stor side, send et UDP-datagram i fuld størrelse, hvis det er den berørte tjeneste, og gentag fra en anden klient på en anden forbindelse. Notér den målte MTU for ruten og den værdi, du valgte, for den næste, der rører profilen, vil ellers behandle tallet som vilkårligt.

Sænk aldrig den indre MTU under 1280, når IPv6 kører over tunnelen, for det er det minimum, enhver IPv6-forbindelse skal kunne bære. En mindre MTU er et faktum om ruten, ikke en ydelsesindstilling, man justerer efter fornemmelse.