Bær en fast indre pakke på 1,500 bytes gennem en VPN

Du har et krav, der ikke bøjer: den fjerne side skal modtage den samme 1,500-byte IP-pakke, som afsenderen udsender, inklusive headere. En tunnel kan ikke pakke den pakke plus sin egen indramning ind i en anden 1,500-byte IP-pakke, så noget i designet må give efter. Rækkefølgen nedenfor er den, jeg bruger i et ændringsvindue: skriv bytebudgettet, dokumentér, hvad underlaget faktisk kan bære, vælg derefter præcis én transportmekanisme, og bekræft den indre pakke på den fjerne side.

Skriv bytebudgettet, før du redigerer en profil

Indkapsling tilføjer bytes på flere lag, og totalen er en egenskab ved din profil snarere end en konstant, du kan slå op. Adressefamilie, valg af cipher, transportprotokol og enhver komprimerings- eller indramningsmulighed flytter tallet, og derfor er en subtraktion kopieret fra en anden udrulning værdiløs som budget. Start med det indre krav, læg den målte overhead pr. pakke fra din egen konfiguration til, og skriv den resulterende ydre størrelse på ændringsbilletten, før nogen redigerer en fil.

To tal bestemmer designet: den største ydre pakke, stien bærer uden fragmentering, og de ekstra bytes, din indkapsling kræver. Når det første er mindre end det andet plus 1,500, skal et af dem ændres. Valget er da snævert snarere end kreativt, og derfor skriver jeg begge tal ned, før vi drøfter muligheder. Intet på tunnellaget komprimerer de bytes væk, og ingen enkelt MTU-værdi fjerner det krav, du har fået.

Undersøg underlaget med ping uden fragmentering

Mål stien i stedet for at stole på interface-MTU’en, fordi det mindste led på den ydre sti er det, der tæller. På Linux sætter -M do do-not-fragment-bitten, og -s tager ICMP-payloaden, så en 1,500-byte ramme svarer ved 1,472 bytes payload, når de 20 byte IP-header og 8 byte ICMP-header er trukket fra. Gå opad med payloaden, indtil testen fejler, og spring derefter til en jumbo-størrelse for at se, om stien overhovedet bærer den.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

En sti, der passerer 1,472 og fejler ved 8,972, kan ikke bære en indre pakke på 1,500 bytes plus overhead i en enkelt ydre pakke. Det er det svar, du havde brug for, før du åbnede VPN-konfigurationen. Det afgør også, hvilket af de næste to afsnit der gælder for dig, så læg de to testresultater ved billetten. At gætte her koster et vedligeholdelsesvindue, fordi en tunnel, der melder sig oppe, ikke siger noget om den største pakke, stien vil acceptere.

Hæv kun stiens MTU, hvor hvert hop er enigt

Jumbo-rammer er en egenskab ende-til-ende, ikke en indstilling, du slår til på de to endepunkter, du tilfældigvis styrer. Hver switch, router og udbyderoverdragelse på den ydre sti skal være enig om den større størrelse, og et enkelt hop på 1,500 bytes vil lydløst kassere den pakke, du netop har gjort større. At hæve kun det lokale interface er den klassiske halve ændring, der får tunnelen til at se brudt ud, mens underlaget stille taber.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Skift interfacet, og undersøg derefter den samme sti igen, før du ændrer noget andet. Hvis testen stadig fejler, rul tilbage med ip link set dev eth1 mtu 1500 og gå videre til fragmentering i stedet for at diskutere med en udbyder om et led, du ikke ejer.

Brug tunnelefragmentering, når underlaget ikke kan vokse

En understøttet fragmenteringsmekanisme under den indre pakke lader flere ydre pakker bære én indre pakke, og tunnelens fjerne endepunkt samler dem igen, før originalen gives videre op i stakken. Community OpenVPNs UDP-fragmentmulighed er én implementering af den idé, og det er ikke det samme som almindelig IP-fragmentering af den ydre pakke. Begge parter skal køre en version, der understøtter formatet, og datastien skal være den, du tror: OpenVPN 3-klienter og kernelaccelererede datakanaler har forskellige grænser, så en profil, der virker på én klient, kan fejle på en anden.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Almindelig ydre fragmentering er den anden mulighed, og den er den svagere. IPv6-routere fragmenterer slet ikke en videresendt pakke, så en for stor ydre pakke dør bare, og afsenderen hører om det kun, hvis den relevante ICMPv6-meddelelse overlever stien. Fragmenter inviterer også til filtrering og tabsforstærkelse, og derfor behandler jeg det som en fallback snarere end en plan.

En strømbaseret ydre bærer omgår størrelsesproblemet ved at segmentere sin egen bytestrøm, og den genopbyggede indre pakke kan stadig være 1,500 bytes. Det er en transportbeslutning med sin egen pris, inklusive den velkendte adfærd med TCP inde i TCP, så tag den bevidst og ikke som bivirkning af en MTU-diskussion.

Bekræft, at den indre pakke ankommer uændret

Verifikation er ikke et vellykket handshake. Optag på tunnelinterfacet i begge ender og sammenlign størrelsen og indholdet af den pakke, applikationen faktisk sendte, med den, den fjerne side modtog.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Hvis optagelsen viser den fuldt størrelse indre pakke i den fjerne ende, virker transportvalget, og den resterende opgave er at dokumentere det. Hvis den intet viser, mens tunnelen melder sig oppe, bliver den ydre pakke kasseret et sted mellem endepunkterne, hvilket sender dig tilbage til testen snarere end til cipher-indstillingerne.

Skriv tre ting på billetten, før du lukker den: det målte ydre budget, den mekanisme du valgte, og den kommando, der beviste, at den indre pakke overlevede. Den næste, der rører denne tunnel, får brug for alle tre, og ingen af dem kan rekonstrueres alene ud fra konfigurationsfilen.