Hvem velger WireGuard-MTU-en: wg-quick, kjernen eller du
WireGuard forhandler ikke om MTU. Oppsettverktøyet, en nettverksbehandler eller konfigurasjonslinjen din bestemmer, og standardverdien er et gjett om banen, ikke en måling.
WireGuard har ingen MTU-forhandling. Den krypterer alt grensesnittet gir den, og sender resultatet, og hvis den innkapslede pakken overstiger banen, blir den droppet eller fragmentert et sted du ikke kan se. Noen må velge grensesnittets MTU, og den noen er verktøyet som fikk grensesnittet opp.
Det finnes tre kandidater, og de er lette å forveksle.
Tre steder verdien kan komme fra
Verdien kan settes eksplisitt i grensesnittkonfigurasjonen, beregnes av oppsettverktøyet fra ruteinformasjon, eller settes av den nettverksbehandleren som eier grensesnittet. Et vanlig wg-kall gjør ingen av disse, fordi wg bare håndterer nøkler og peers. MTU-en bor på nettverksgrensesnittet, og derfor er ip link show wg0 der du leser den.
Hvis du er usikker på hvilket tilfelle som gjelder, les MTU-en først og finn deretter ut hvem som startet grensesnittet.
Avgjør ut fra hvem som kjører grensesnittet
Hvis wg-quick starter det, vinner en eksplisitt MTU-linje, og ellers beregner den en verdi. Hvis en nettverksbehandler starter det, avgjør den behandlerens profil. Hvis en container-runtime eller en leverandørklient starter det, les dokumentasjonen deres i stedet for å anta wg-quick-atferd.
Avgjørelsen er ikke hvilket tall som er best abstrakt. Den er hvilken komponent du faktisk kan konfigurere.
Hva standardberegningen gjør
wg-quick slår opp ruten til peerens endepunkt, tar MTU-en til det utgående grensesnittet og trekker fra innkapslingskostnaden. Med et IPv4-ytterhode er det rundt 60 byte; med IPv6 er det rundt 80. Resultatet begrenses slik at en bane på 1500 byte gir 1420 i stedet for en verdi som bare fungerer på én adressefamilie. Det er en rimelig standard, ikke en måling av banen din.
Den kan ikke vite om en senere tunnel, en mobil lenke eller en filtrert ICMP-bane.
Grensen skjuler et reelt spørsmål. Hvis banen din virkelig er 9000 byte ende til ende, etterlater 1420 ytelse på bordet, og hvis banen er 1400, er 1420 allerede for stor. Standardverdien er et kompromiss, og den bør behandles som det.
Når banen endrer seg under deg
En bærbar PC som vandrer fra Ethernet til Wi-Fi til et telefonhotspot beholder grensesnitt-MTU-en den startet med. Den ytre banen kan nå være mindre, og ingenting forhandler på nytt. Nestede tunneler gjør det verre, fordi hvert lag trekker fra sin egen kostnad fra samme budsjett. Verdien som fungerte på kontoret, er ikke verdien som fungerer på flyplassen.
En nylig handshake beviser at nøklene virker. Det beviser ingenting om hvorvidt store pakker får plass.
Test ett tall om gangen
Behold samme applikasjon og destinasjon, endre én verdi og mål. ping -M do -s 1372 tester en pakke på 1400 byte med DF-biten satt, og det er den formen for test du vil ha. Hvis små forespørsler virker og store stopper, har du et størrelsesproblem og ikke et ruteproblem.
Endre bare MTU-en. Å justere flere pakkealternativer samtidig forteller deg ingenting om hvilket som betydde noe.
Og ikke forvent at en MTU-endring retter en manglende returrute, en videresendingsregel eller en DNS-feil. De gir også symptomer uten trafikk, og de har sine egne tester. wg-quick-håndboken dokumenterer det automatiske valget.