OpenVPN varnar för inkonsekvent MTU-användning: vad varningen jämför
Varningen jämför partnernas alternativ, inte paketstorlekar. Skilj ett föråldrat link-mtu-värde från ett verkligt MTU-problem på vägen och testa sedan med en storleksmedveten sond.
Den varningen rapporterar en jämförelse mellan partnernas alternativ, inte en mätning av vägen mellan dem. Folk läser den som ”MTU är fel” och ändrar talet tills raden försvinner. Det behandlar en konfigurationsjämförelse som en nätverksmätning, och det gör ofta tunneln sämre medan loggen blir tystare. Det användbara första steget är att avgöra vilket av de två problemen du faktiskt har.
Tre villkor avgör svaret: vad parterna jämför, om värdet är föråldrat och vilket symptom som finns utöver varningen.
Varningen jämför alternativ, inte paket
OpenVPN-partner utbyter sina alternativsträngar under handskakningen och jämför dem som en del av alternativkonsistenskontrollen. När ena sidan rapporterar link-mtu eller tun-mtu annorlunda än den andra registreras avvikelsen med båda värdena. Det utbytet skickar aldrig ett stort paket för att se vad som händer, så varningen beskriver konfiguration snarare än kapacitet. En tunnel kan bära trafik i full storlek och ändå skriva ut den, eller misslyckas med stora paket och inte skriva ut något alls.
Behåll hela varningen med dess lokala och avlägsna värde. Paret är beviset; det enskilda talet du minns är det inte.
Varför link-mtu är föråldrat
OpenVPN 2.6 förklarar link-mtu föråldrat eftersom variabla rubriker och förhandlade chiffer gör ett fast länkvärde opålitligt. Alternativet antog en paketlayout som protokollet inte längre garanterar, så en gammal profil med ett bokstavligt link-mtu beskriver en avsikt som den nuvarande koden inte kan uppfylla. Att kopiera talet till en ny profil sprider ett föråldrat antagande. Läs det som en del av den gamla profilens historia, inte som en rekommendation.
Konsistenskontrollen har också ett valfritt OCC-värde knutet till tun-mtu, som ändrar vad som jämförs utan att ändra vad nätverket bär. Att sätta det får inte större paket att passa.
Rätta profilen innan du testar vägen
Rätta till en oavsiktlig avvikelse genom den som äger profilerna, och kom ihåg att en ändring på serversidan påverkar varje klient. Redigera profilen som instansen faktiskt läser in, inte en export i en nedladdningsmapp. Anslut sedan en testklient igen och notera vilken varning som överlever. Om meddelandet byter form i stället för att försvinna jämför du andra alternativ än du tror.
En delad server behöver få sin klientförteckning kontrollerad innan ett globalt värde flyttas, eftersom värdet som passar en plats kan förstöra en annan.
Testa sedan det symptom du faktiskt har
Om stora överföringar fastnar medan små förfrågningar lyckas, mät paketstorleken mot en kontrollerad destination. En sond som sätter don't-fragment-biten och ökar nyttolastens storlek hittar vägens användbara MTU långt mer tillförlitligt än en ping som bara lyckas. Ta med programmet som misslyckas i testet: en ICMP-timeout kan spegla filtrering, och en liten lyckad ping säger ingenting om ett programpaket i full storlek.
mssfix begränsar den MSS som annonseras för TCP-sessioner inne i tunneln, vilket hjälper TCP och inte gör något för en inre UDP-belastning. Fragmentering och offload har sina egna kompatibilitetsvillkor. Välj en mekanism för det påvisade problemet i stället för att ändra flera samtidigt för att tysta en logglinje.
Behåll de effektiva värdena med resultatet
Anteckna de ursprungliga och korrigerade effektiva värdena bredvid resultatet av en verklig överföring. Det paret är det som skiljer ett föråldrat profilalternativ från ett MTU-problem på vägen som finns oberoende. Utan det ser nästa läsare en varning som försvann och antar att nätverket ändrades.
Att undertrycka konsistenskontrollen försonar ingenting. Det tar bort observationen och lämnar båda konfigurationerna som de var.