Frakte en fast indrepakke på 1,500 byte gjennom en VPN

Du har et krav som ikke bøyer seg: den andre siden må motta den samme 1,500-byte IP-pakken som senderen legger ut, inkludert headere. En tunnel kan ikke pakke den pakken pluss sin egen framing inn i en andre 1,500-byte IP-pakke, så noe i designet må gi etter. Rekkefølgen nedenfor er den jeg bruker i et endringsvindu: skriv bytebudsjettet, bevis hva underlaget faktisk kan bære, velg deretter nøyaktig én transportmekanisme og bekreft indrepakken på den andre siden.

Skriv bytebudsjettet før du redigerer en profil

Innkapsling legger til byte på flere lag, og summen er en egenskap ved profilen din og ikke en konstant du kan slå opp. Adressefamilie, valg av siffer, transportprotokoll og enhver komprimering eller framing-valg flytter tallet, og derfor er en subtraksjon kopiert fra en annen utrulling verdiløs som budsjett. Start med det indre kravet, legg til den målte overheaden per pakke for din egen konfigurasjon, og skriv den resulterende ytre størrelsen på endringssaken før noen redigerer en fil.

To tall avgjør designet: den største ytre pakken veien bærer uten fragmentering, og de ekstra bytene innkapslingen din trenger. Når det første er mindre enn det andre pluss 1,500, må ett av dem endres. Valget blir da smalt og ikke kreativt, og derfor skriver jeg ned begge tallene før jeg diskuterer alternativer. Ingenting på tunnellaget komprimerer de bytene bort, og ingen enkelt MTU-heltall fjerner kravet du fikk.

Sondér underlaget med do-not-fragment-ping

Mål veien i stedet for å stole på grensesnittets MTU, fordi den minste lenken i den ytre veien er den som teller. På Linux, -M do setter do-not-fragment-biten og -s tar ICMP-nyttelasten, så en ramme på 1,500 byte svarer med 1,472 byte nyttelast når 20 byte IP-header og 8 byte ICMP-header er trukket fra. Øk nyttelasten til sonden feiler, og hopp deretter til en jumbo-størrelse for å se om veien bærer den i det hele tatt.

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 vei som passerer 1,472 og feiler på 8,972 kan ikke bære en indrepakke på 1,500 byte pluss overhead i én enkelt ytre pakke. Det er svaret du trengte før du åpnet VPN-konfigurasjonen. Det avgjør også hvilken av de to neste seksjonene som gjelder for deg, så hold de to sonderesultatene ved endringssaken. Å gjette her koster et vedlikeholdsvindu, fordi en tunnel som rapporterer at den er up ikke forteller deg noe om den største pakken veien vil godta.

Øk veiens MTU bare der hvert hopp er enig

Jumbo-rammer er en ende-til-ende-egenskap, ikke en innstilling du slår på på de to endepunktene du tilfeldigvis kontrollerer. Hver svitsj, ruter og leverandøroverlevering på den ytre veien må være enig om den større størrelsen, og ett enkelt hopp på 1,500 byte vil stille forkaste pakken du nettopp gjorde større. Å øke bare det lokale grensesnittet er den klassiske halve endringen som får tunnelen til å se ødelagt ut mens underlaget stille slipper.

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

Endre grensesnittet, og sonder deretter den samme veien på nytt før du endrer noe annet. Hvis sonden fortsatt feiler, rull tilbake med ip link set dev eth1 mtu 1500 og gå over til fragmentering i stedet for å krangle med en leverandør om en lenke du ikke eier.

Bruk tunnelfragmentering når underlaget ikke kan vokse

En støttet fragmenteringsmekanisme under indrepakken lar flere ytre pakker bære én indrepakke, og det andre tunnelendepunktet setter dem sammen igjen før det leverer originalen til stakken. Community OpenVPNs UDP-fragmentvalg er én implementering av den ideen, og det er ikke det samme som vanlig IP-fragmentering av den ytre pakken. Begge parter må kjøre en versjon som støtter formatet, og datastien må være den du tror: OpenVPN 3-klienter og kernakselererte datakanaler har forskjellige grenser, så en profil som fungerer på én klient kan feile på en annen.

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

Vanlig ytre fragmentering er det andre alternativet, og det er det svakere. IPv6-rutere fragmenterer ikke en videresendt pakke i det hele tatt, så en for stor ytre pakke dør bare, og senderen får vite det først hvis den relevante ICMPv6-meldingen overlever veien. Fragmenter inviterer også til filtrering og tapforsterkning, og derfor behandler jeg dette som en reserve og ikke en plan.

En strømbasert ytre bærer omgår størrelsesspørsmålet ved å segmentere sin egen bytestrøm, og den rekonstruerte indrepakken kan fortsatt være 1,500 byte. Det er en transportbeslutning med sin egen kostnad, inkludert den kjente oppførselen til TCP inne i TCP, så ta den bevisst og ikke som en bivirkning av en MTU-diskusjon.

Bekreft at indrepakken ankommer uendret

Verifisering er ikke et vellykket handshake. Ta opp på tunnelgrensesnittet i begge ender og sammenlign størrelsen og innholdet i pakken applikasjonen faktisk sendte med den den andre siden mottok.

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 opptaket viser den fullstore indrepakken i den andre enden, fungerer transportvalget, og det som gjenstår er å dokumentere det. Hvis det ikke viser noe mens tunnelen rapporterer at den er up, blir den ytre pakken forkastet et sted mellom endepunktene, noe som sender deg tilbake til sonden og ikke til sifferinnstillingene.

Skriv tre ting i endringssaken før du lukker den: det målte ytre budsjettet, mekanismen du valgte, og kommandoen som beviste at indrepakken overlevde. Den neste personen som tar i denne tunnelen trenger alle tre, og ingen av dem kan rekonstrueres fra konfigurasjonsfilen alene.