OpenVPN Connect avvisar fragment: rätta till profilens källa

Felet kommer vid import, före någon förhandling, och namnger ett direktiv som klienten vägrar acceptera. OpenVPN Connect kör OpenVPN 3-bibliotekskod, som inte alls implementerar gemenskapsklientens fragment-alternativ. Det gör detta till en kompatibilitetsfråga mellan två ändpunkter, inte en trimningsfråga om paketstorlek.

Raderar du raden får du en fil som klienten kan parsa, och en server som kanske fortfarande väntar sig formatet som raden beskrev. Gå igenom det från importskärmen och utåt innan du redigerar något.

Var importen stannar

Importören parsar direktiv innan den kontaktar servern, så ett avslag där är ett lokalt beslut om syntax och inte ett nätverksresultat, och OpenVPNs lista över direktiv som inte stöds registrerar samma begränsning. Det förklarar hur en fil kan fungera i gemenskapsklienten och misslyckas i Connect på samma maskin. Läs direktivnamnet i meddelandet och spara originalfilen, eftersom den texten är det enda beviset för vad klienten invände mot. Ett importfel och en anslutningstimeout kommer från olika faser och förtjänar olika svar.

Om meddelandet namnger fragment kvarstår frågan om även servern är beroende av det. Svara på det innan du rör profilen du fick.

Vad fragment ändrar i gemenskapsklienten

I gemenskapsklienten slår direktivet på OpenVPNs egen datagramfragmentering, som delar nyttolasten innan den når det yttre IP-lagret. Den finns för att överleva vägar som släpper stora UDP-datagram och för att hålla en tunnel användbar där vägens MTU-upptäckt inte går att lita på. Det är inte synonymt med att sänka gränssnittets MTU, och det är inte IP-fragmentering utförd av operativsystemet. En klient utan mekanismen får den inte genom att sänka en siffra.

Eftersom inställningen också bor i serverkonfigurationen ändrar det bara din sida att ta bort den från din kopia. Servern väntar kanske fortfarande på en motpart som förstår alternativet, och en profil som parsas är ännu inte en session som etableras. De två fakta förklarar det förvirrande mellantillståndet där en redigerad fil ansluter och sedan fastnar.

Be om en profil byggd för den här klienten

Den rena vägen är en andra profil dokumenterad för OpenVPN Connect, om tjänsten publicerar en. Många leverantörer gör det, och skillnaden är oftast direktiven de utelämnar, inte ändpunkten de pekar på. Be om den med klientnamnet i stället för att beskriva felet, eftersom en supportdesk kan matcha en profil till en klient mycket snabbare än den kan diagnostisera en strippad fil.

Om du driver servern är beslutet bredare än din egen klient. Stänger du av fragmenteringen drabbas varje motpart, även de som behövde den för att hålla sig anslutna över en dålig väg. Att publicera en andra lyssnare eller en andra konfiguration för den drabbade klienten håller befintliga användare igång medan den nyare klienten får något den kan parsa. Hur du än gör, skriv ned vilken konfiguration som betjänar vilken klient, för den kopplingen försvinner annars snabbt.

Verifiera anslutningen, inte bara importen

En lyckad import bevisar bara att parsern godtog filen. Etablera tunneln med gemenskapsklienten på en maskin du kontrollerar, med samma profil, och läs loggen för transport- och krypteringsförhandling. Kommandona nedan gör det utan att skrivbordsappen är i vägen.

openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/

Loggen visar var försöket stannade: ett alternativfel visas före något TLS-utbyte, medan ett autentiserings- eller krypteringsfel visas efter. Om tunneln kommer upp och begäran ändå misslyckas har problemet flyttat från kompatibilitet till routing. Jämför det med Connects beteende i samma nätverk innan du drar någon slutsats om servern.

Håll den fungerande profilen och klientversionen bredvid anteckningen. En framtida klientutgåva kan lägga till stöd för ett direktiv, och det ändrar svaret utan att någon rör servern.