Hvorfor en VPN henger på store overføringer men ikke på små
Små forespørsler svarer mens store overføringer fryser. Sammenlign grensesnittgrensen, stigrensen og den annonserte TCP-nyttelasten før du kopierer en fast MTU.
En side lastes, en ping lykkes, og en filkopi henger på samme punkt hver gang. Det mønsteret peker på pakkestørrelse framfor båndbredde eller påloggingsinformasjon. Innkapsling legger til byte i hver pakke, så en nyttelast som passet på den opprinnelige veien, kan overskride grensen når den sendes gjennom en tunnel. I disse samtalene kalles tre forskjellige tall MTU, og å blande dem fører til en innstilling som reparerer én applikasjon og ødelegger en annen.
Tre tall folk kaller MTU
Grensesnitt-MTU er den konfigurerte grensen for en pakke på den lenken. Sti-MTU er den minste grensen langs ruten, og den oppdages i stedet for å konfigureres. TCP MSS er størrelsen på nyttelasten en motpart oppgir at den kan motta, og den utledes fra de to andre i stedet for å være en egen fysisk grense.
En tunnel har et indre og et ytre perspektiv. Den ytre pakken bærer den innkapslede pluss de hodene protokollen trenger, så den brukbare indre størrelsen er mindre enn den ytre veien tillater. Veien til VPN-serveren er også forskjellig fra serverens vei til målet.
Oppdagelse av sti-MTU lar en avsender lære den fungerende størrelsen, men det avhenger av at tilbakemelding kommer fram. Når en mellomliggende enhet filtrerer de relevante ICMP-meldingene, fortsetter avsenderen å sende pakker som aldri fullføres, og det er det klassiske svarte hullet. Symptomet er særegent når man kjenner det: håndtrykket lykkes, den første nyttelasten i full størrelse forsvinner, og forbindelsen tilbakestilles eller henger til slutt. Ingenting i applikasjonsloggen ser ut som et nettverksproblem.
Undersøk veien med en nyttelast du kontrollerer
En test er bevis om én rute og én størrelse, ikke en anbefalt innstilling. Bruk en vert som svarer, og endre bare størrelsen på nyttelasten.
ping -M do -s 1372 -c 2 203.0.113.20 ping -4 -f -l 1372 vpn.example
Den første kommandoen sender en Linux-test med fragmentering slått av og en nyttelast på 1372 byte, og den andre gjør det samme på Windows der nyttelasten settes med -l. Et svar betyr at den størrelsen overlevde veien. En melding om at fragmentering er nødvendig, er informativ, mens en tidsavbrudd er tvetydig fordi verten eller en mellomliggende enhet ganske enkelt kan droppe ICMP.
Gå størrelsen ned i noen få trinn i stedet for binærsøk til byten. Du prøver å fastslå om det finnes et størrelsestak, ikke å publisere et tall for hvert nettverk. Tallet du finner gjelder for denne veien, denne protokollen og denne adressefamilien.
IPv4 og IPv6 fragmenterer ulikt, så et testresultat fra den ene familien sier ingenting om den andre. Test familien applikasjonen faktisk bruker.
MSS-clamping hjelper bare TCP
I TCP forhandles den effektive nyttelasten under håndtrykket, og en ruter på veien kan skrive den verdien nedover slik at begge ender sender mindre segmenter. Det er hva MSS-clamping gjør, og det virker uten å røre klienten i det hele tatt.
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ip link show tun0
Den første regelen clamper den annonserte MSS til sti-MTU for videresendte TCP-håndtrykk, og den andre viser tunnelgrensesnittets egen MTU slik at du kan sammenligne den med det veien tillater. Clamping er den minst inngripende rettelsen for en TCP-applikasjon som henger etter håndtrykket.
For UDP gjør den ingenting. En tale- eller spillklient som sender store datagrammer, vil ignorere en MSS-innstilling helt, fordi det ikke finnes noe håndtrykk å skrive om. Hvis applikasjonen som feiler er UDP, se i stedet på klientens egne valg for pakkestørrelse. De to protokollene feiler ulikt og repareres med ulike verktøy, derfor hører protokollen hjemme i første setning i saken.
OpenVPN eksponerer valg som tun-mtu, mssfix og fragmenteringsrelaterte innstillinger, og oppførselen deres avhenger av versjonen og av om datakanalen er AEAD. Les håndboken for versjonen som brukes, og endre én innstilling om gangen.
Endre én støttet innstilling og gjenta begge kjøringene
Behold den opprinnelige profilen, endre én støttet verdi, og gjenta både den lille forespørselen som virket og den store overføringen som feilet. Hvis bare den store endres, jaget du størrelse. Hvis begge endres, flyttet noe annet seg med den.
En lavere verdi kan redusere symptomet mens den legger til overhead, så det minst mulige tallet er ikke målet. Målet er en størrelse som veien bærer pålitelig med minst mulig sløsing. Noter verdien, veien og klientversjonen i saken, fordi samme tall brukt et annet sted er en gjetning.
Hvis samme profil virker fra et annet klarert nettverk, behold den forskjellen i diagnosen i stedet for å erklære klienten reparert. Variabelen som endret seg er veien, og veien er det testen målte.