OpenVPN över PPPoE: sänka link-mtu, tun-mtu eller mssfix?

Ping svarar, DNS löser upp, och varje sida som behöver ett fullt segment hänger sig. På en länk som lägger till sin egen inkapsling tappar vägen tyst några dussin byte av budgeten, och en profil skriven för rent Ethernet fortsätter att begära paket som linjen inte kan bära. Anslutningen är inte långsam; den kastar precis de paket som betyder något.

Tre alternativ kan åtgärda detta, och de verkar på olika lager. Att välja fel gör antingen ingenting eller gör tunneln ömtålig på ett nytt sätt, så valet börjar med vad vägen faktiskt stöder.

Tre rattar, tre olika lager

link-mtu är den yttre budgeten: den krypterade nyttolasten plus OpenVPN-huvudet, UDP-huvudet och det yttre IP-huvudet. Det beskriver vad som lämnar maskinen, och därför är det talet som den fysiska vägen begränsar.

tun-mtu är den inre budgeten: gränssnittet som din trafik ser. Det är exakt tunnelns overhead större än vad vägen kan bära, och OpenVPN härleder det vanligtvis i stället för att tvinga dig att ställa in det.

mssfix är en helt annan mekanism. Den skriver om den maximala segmentstorlek som annonseras under TCP-handskakningar, så att TCP-partner väljer segment som passar efter inkapslingen. Den ändrar inte gränssnittets MTU och har ingen effekt på UDP.

Om du ställer in link-mtu uttryckligen drar OpenVPN av sin egen overhead för att härleda den inre MTU:n. Den overheaden är inte en fast konstant; den beror på chiffer och autentisering, och därför kan ett värde kopierat från ett forum vara fel på en annan profil. Att ställa in både link-mtu och tun-mtu ger klienten två motstridiga instruktioner.

Mät vägen innan du väljer ett tal

Mät från det fysiska gränssnittet, inte inifrån tunneln, och kom ihåg att ping rapporterar nyttolasten, inte paketstorleken. Lägg till 28 byte för IPv4- och ICMP-huvudena innan du jämför nyttolasten med en ram på 1500 byte, och ha den korrigeringen i åtanke när en part rapporterar ett annat tal.

På en Linux-klient förbjuder ping -M do -s 1472 fragmentering och misslyckas om paketet är för stort. Sänk nyttolasten tills det går igenom, och lägg sedan till 28 för att få vägens MTU. PPPoE kostar 8 byte, så 1492 är normalt på DSL. DS-Lite och vissa mobila vägar kostar 40 eller mer, och svaret är vanligtvis lägre än den nominella länkhastigheten antyder.

Om varje ping-storlek lyckas men stora överföringar fortfarande hänger sig, misstänk ett svart hål i stället för en enkel storleksgräns. Ett ICMP-meddelande om nödvändig fragmentering filtreras någonstans längs vägen, så avsändaren lär sig aldrig att krympa, och bara de flöden som behöver ett stort segment märker det.

Begränsa TCP först, krymp tunneln sedan

TCP-handskakningar är det enda som mssfix rör, vilket vanligtvis gör den till den minst ingripande kontrollen att prova först. Ställ in den strax under vägens verkliga budget, skicka samma värde från servern så att båda ändarna är överens, och testa en stor nedladdning igen. Om hängningen försvinner var problemet TCP-segmentstorleken, och ingenting annat behöver ändras.

Sänk den inre MTU:n när den berörda trafiken inte är TCP. En UDP-tjänst, en tunnel inuti tunneln eller ett program som skickar datagram i full storlek fortsätter att misslyckas efter en MSS-begränsning eftersom ingenting skriver om dess paketstorlek. Minska tun-mtu för det fallet, eller ställ in link-mtu och låt klienten härleda det inre värdet, men aldrig båda.

Ta inte till det gamla fragmenteringsalternativet. Det delade paket inuti tunneln, lade till overhead och har avvecklats av goda skäl; modernt OpenVPN förväntar sig att vägen beskrivs noggrant.

Varför små mätningar fortsätter att fungera

DNS-frågor, ICMP-ekon och TCP-handskakningar ligger alla långt under storleken som misslyckas. Tunneln ser därför frisk ut i varje snabbt test, medan TLS-handskakningar och HTTP-svar misslyckas tyst. Just den kombinationen, en fungerande traceroute och en webbläsare som hänger sig på det första stora svaret, är signalen att leta efter. Ta till en mätning i full storlek innan du tar till en ny profil.

Verifiera med trafiken som misslyckades. Hämta en stor sida, skicka ett UDP-datagram i full storlek om det är tjänsten som berörs, och upprepa från en andra klient på en annan länk. Anteckna den uppmätta vägens MTU och värdet du valde, för nästa person som rör profilen kommer annars att behandla talet som godtyckligt.

Sänk aldrig den inre MTU:n under 1280 när IPv6 går över tunneln, eftersom det är det minimum som varje IPv6-länk måste bära. En mindre MTU är ett faktum om vägen, inte en prestandainställning att finjustera på känsla.