OpenVPN rapporterer inkonsekvent bruk av MTU: hva sammenligningen i advarselen viser

Advarselen forteller om en sammenligning mellom partenes valg, og ikke om en måling av veien mellom dem. Mange leser den som «MTU-en er feil» og justerer tallet helt til linjen forsvinner. Da behandles en konfigurasjonssammenligning som en nettverksmåling, og det gjør ofte tunnelen dårligere samtidig som loggen blir roligere. Det nyttige første steget er å avgjøre hvilket av de to problemene du egentlig har.

Tre forhold avgjør svaret: hva partene sammenligner, hvorvidt verdien er gammel, og hvilket symptom som finnes utenom advarselen.

Advarselen sammenligner valg, ikke pakker

Partene i OpenVPN utveksler valgstrenger under håndtrykket og sammenligner dem som en del av konsistenskontrollen. Når én side oppgir link-mtu eller tun-mtu ulikt den andre, blir avviket notert med begge verdiene. Utvekslingen sender aldri en stor pakke for å se hva som skjer, så advarselen beskriver konfigurasjon og ikke kapasitet. En tunnel kan frakte trafikk i full størrelse og likevel skrive ut advarselen, eller svikte på store pakker og ikke skrive ut noe.

Ta vare på hele advarselen sammen med den lokale og den eksterne verdien. Paret utgjør beviset; det enkeltallet du husker, gjør det ikke.

Hvorfor link-mtu er utdatert

OpenVPN 2.6 markerer link-mtu som utdatert fordi variable headere og forhandlede chifre gjør en fast lenkeverdi upålitelig. Valget forutsatte en pakkeutforming som protokollen ikke lenger garanterer, så en gammel profil med en bokstavelig link-mtu beskriver en hensikt som dagens kode ikke kan innfri. Kopiering av tallet inn i en ny profil sprer en utdatert antakelse. Les det som en del av historikken til den gamle profilen, ikke som en anbefaling.

Konsistenskontrollen har også en valgfri OCC-verdi knyttet til tun-mtu, og den endrer hva som sammenlignes uten å endre hva nettverket frakter. Å sette den gjør ikke at større pakker får plass.

Rett profilen før du tester veien

Rett opp et uønsket avvik gjennom den som eier profilene, og husk at en endring på tjeneren rammer hver klient. Rediger profilen som instansen faktisk laster inn, ikke en eksport som ligger i en nedlastingsmappe. Koble så til én testklient på nytt og legg merke til hvilken advarsel som består. Dersom meldingen endrer form i stedet for å forsvinne, sammenligner du andre valg enn du tror.

En delt tjener trenger kontroll av klientoversikten før en global verdi flyttes, fordi verdien som passer ett sted, kan ødelegge et annet.

Test så symptomet du faktisk har

Dersom store overføringer stopper mens små forespørsler lykkes, mål pakkestørrelsen mot en kontrollert destinasjon. En sonde som setter don't-fragment-biten og øker nyttelastens størrelse, finner den brukbare MTU-en på veien langt sikrere enn en ping som bare lykkes. Ta med applikasjonen som feiler i testen: en ICMP-tidsgrense kan gjenspeile filtrering, og en liten vellykket ping sier ingenting om en applikasjonspakke i full størrelse.

mssfix begrenser MSS som annonseres for TCP-økter inne i tunnelen, noe som hjelper TCP og ikke gjør noe for en indre UDP-last. Fragmentering og offload har sine egne kompatibilitetsvilkår. Velg én mekanisme for det påviste problemet i stedet for å endre flere samtidig for å dempe en logglinje.

Ta vare på de effektive verdiene sammen med resultatet

Skriv ned de opprinnelige og korrigerte effektive verdiene ved siden av resultatet av en virkelig overføring. Det er dette paret som skiller et utdatert profilvalg fra et MTU-problem på veien som eksisterer uavhengig. Uten det ser neste leser en advarsel som er borte, og antar at nettverket er endret.

Å undertrykke konsistenskontrollen løser ingenting. Det fjerner observasjonen og lar begge konfigurasjonene stå som de var.