VPN-MTU-mytar: kvifor pakkane dine krympar og kvar plassen vert av

Nokon fortel deg at VPN-et "mistar pakkar på grunn av MTU", du set tunnelen til 1400, og overføringa verkar igjen. Det resultatet kjennest som ein diagnose. Som regel er det ein tilfeldigheit i aritmetikken: du valde eit tal som er lite nok til å passe under ei grense du aldri identifiserte, og du vil møte den same grensa igjen på det neste nettet med eit anna budsjett.

To mytar forårsakar det meste av dette. Den første er at tunnelgrensesnittet sin MTU er banen sin MTU. Den andre er at innkapsling kostar "éin header" og at PPPoE ikkje kostar noko som er verdt å telje. Begge er feil på måtar som får talet du vel til å sjå vilkårleg ut når det faktisk er bestemt.

Myte éin: tunnelens MTU er banen sin MTU

Verdien du set på eit tunnelgrensesnitt er eit lokalt løfte om den største indre pakken implementasjonen vil levere nedover. Den reelle kapasiteten til banen er ein eigenskap ved kvar lenkje mellom deg og den fjerne enden, og han kan endre seg når ei rute blir endra, når ei mobilforbindelse blir overteken, eller når trafikken tek ein annan peering. Ein konfigurert 1500 fortel kva verten din byggjer, ikkje kva nettet ber.

Oppdaging av banen sin MTU finst for å sameine dei to, og ho er avhengig av tilbakemelding. Med IPv4 skal ein rutar som ikkje kan videresende ein pakke i full storleik, sende ei ICMP-melding "fragmentation needed", og avsendaren senkjer anslaget sitt. Med IPv6 er motstykket ei Packet Too Big-melding, og rutarar fragmenterer ikkje i det heile undervegs. Når den tilbakemeldinga blir filtrert, held avsendaren fram med å produsere pakkar som banen ikkje kan bere, og ingenting fortel han kvifor.

Myte to: innkapsling kostar éin header

Tel dei ytre laga ærleg. Ein ytre IP-header er 20 byte ved IPv4 eller 40 ved IPv6. UDP-innkapsling for NAT-gjennomgang legg til 8. Tunnelprotokollen legg til sin eigen header, ein initialiseringsvektor eller nonce, utfylling til blokk- eller justeringsgrensa til chifferen, ein trailer og ein integritetskontrollverdi. Avhengig av protokoll og chiffer ligg totalen komfortabelt i titals byte før den indre pakken i det heile byrjar.

Trekk så frå igjen for dei indre pakkane sine eigne headere. Eit TCP-segment inne i tunnelen ber sin eigen 20-byte IP-header og 20-byte TCP-header, og MSS-en til TCP blir utleia frå MTU-en, ikkje frå den nominelle nyttelasta til tunnelen. Derfor kan ping med mindre nyttelast lukkast medan ei filoverføring stoppar: verktya testar ulike ting, og berre eitt av dei øvar på eit TCP-segment i full storleik.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Den første kommandoen rapporterer den konfigurerte tunnel-MTU-en. Dei to probane sender ei nyttelast på 1472 byte, som med 28 byte IPv4- og ICMP-headere er ein pakke på 1500 byte, og deretter ein mindre. Viss den store proben feilar heilt og den litle lukkast, har du ein storleiksavhengig feil og ikkje eit generelt ruteproblem.

Myte tre: PPPoE gir deg framleis reine 1500

Ei vanleg PPPoE-tilgangslenkje ber ikkje ein IP-pakke på 1500 byte. PPPoE-headeren pluss PPP-protokollfeltet tek 8 byte inne i Ethernet-ramma, noko som lèt 1492 att til IP-pakken. Det er den tradisjonelle grensa som er skildra i RFC 2516. Køyrer du ein VPN over ei slik lenkje, kjem overheaden til tunnelen ut av dei 1492, ikkje av 1500.

RFC 4638 definerer ein måte å forhandle om ei større PPP-nyttelast når både tilgangskonsentratoren og utstyret til kunden støttar det, og derfor beviser "denne forbindelsen bruker PPPoE" åleine ikkje eit bestemt tal. Ei lokal innstilling kan ikkje tvinge eit mellomliggjande apparat til å godta ein pakke det aldri vart konfigurert for, så det nyttige spørsmålet er kva lenkja faktisk forhandla, ikkje kva etiketten seier.

Kvifor feilen verkar selektiv

At små førespurnader lukkast og store overføringar stoppar, er den klassiske signaturen på eit svart hòl i banen sin MTU. Handtrykket, DNS-spørjinga og API-kallet passar alle; masseoverføringa produserer segment i full storleik som døyr på éi lenkje, og ICMP-meldinga som skulle ha rapportert problemet, kjem aldri fram. Sambandet ser fint ut og nedlastinga heng, noko som får folk til å sjå på tenaren i staden for banen.

Ein annan, skyld feil er å blande tre tal: grensesnittet sin MTU, MSS-en til TCP og protokollen si eiga fragmenterings- eller utfyllingsinnstilling. MSS-clamping på ein rutar skriv om den annonserte MSS-en slik at avsendaren byggjer mindre segment; det endrar ikkje tunnel-MTU-en og hjelper ikkje UDP-trafikk. Å gi alle tre same talet fordi dei verkar skylde, er måten ei velmeint endring øydelegg eit fungerande oppsett.

Kva skal endrast, og i kva rekkjefølgje

Byrja med bevis. Stadfest med probane ovanfor at feilen er storleiksavhengig, og finn den minste storleiken som går gjennom og den største som feilar. Kontroller den reelle MTU-en til tilgangslenkja før du gir tunnelen skulda; ei PPPoE-lenkje avgrensar budsjettet før VPN-en din rører henne. Noter dei opphavlege verdiane slik at endringa kan rullast tilbake.

Bruk deretter den minste justeringa klienten dokumenterer. Mange klientar tilbyr ein tunnel-MTU pluss eit MSS-reparasjonsval, og MSS-valet er ofte den betre spaken for TCP fordi det når avsendaren utan å krympe kvar pakke. Test same destinasjon og same overføring på nytt, og noter tala du landa på. Ein tunnelverdi som verkar på eitt tilgangsnett, er ikkje ein universell konstant, og neste stad vil ha sitt eige budsjett.