TUN/TAP: ogiltigt argument — OpenVPN-ramning stämmer inte

Klienten autentiserar, loggen säger ansluten, och inget paket korsar tunneln. Servern avslutar försöket med write to TUN/TAP: Invalid argument (code=22), vilket ser ut som ett drivrutinsfel och oftast inte är det. På routrar och små Linux-servrar betyder den raden oftast att de två parterna inte är överens om hur datapaket ramas in, så kärnan avvisar den dekrypterade bufferten den fick. Routingen är inte testad vid den punkten.

En korrekt routingtabell och ett trasigt ramavtal ser likadana ut från klienten: ansluten, och ingenting fungerar.

Tunneln kommer upp och ingenting korsar den

Skrivfel på tunnelenheten uppstår efter dekryptering och före routing. Daemonen dekrypterar ett paket, lämnar det till gränssnittet, och gränssnittet avvisar det eftersom bufferten inte matchar vad den enheten förväntar sig. Kod 22 är det generiska svaret för ogiltigt argument, så den användbara informationen är lagret: detta är datavägen och inte handskakningen. Om trafiken fungerade igår och stannade idag utan konfigurationsändring, misstänk en paket- eller firmwareuppdatering som flyttade ett standardvärde innan du misstänker nätverket.

Läs loggen kring konfigurationen av datakanalen i stället för det första felet. Det förhandlade komprimeringsläget, dev-typen och de pushade alternativen visas alla vid högre detaljrikedom, och de berättar vilken av de tre avvikelserna du har.

Komprimering är ramning, inte bandbredd

När komprimering är aktiverad bär varje datapaket ett huvud som beskriver hur det kodades, och båda ändarna måste vara överens om det huvudet. En server som fortfarande bär comp-lzo från en gammal exempelkonfiguration, parad med en klient utan komprimeringsrad, ger exakt detta fel: servern förväntar sig ett huvud som klienten aldrig skrev. Att blanda comp-lzo med compress lz4-v2 misslyckas på samma sätt, eftersom algoritmerna skiljer sig även om båda kallas komprimering. Alternativet är ett ramavtal och inte en bandbreddsfunktion på moderna länkar.

Versionsbeteende lägger till en fälla. 2.5-serien började utfärda föråldravarningar för komprimeringsalternativ, och 2.6 drar en gräns mellan att avvisa komprimerade paket och att bara lämna data okomprimerade. En firmwareuppdatering på routern kan därför ändra det effektiva avtalet utan att någon redigerar tunneln.

Rikta in båda ändarna eller ta bort det från båda

Räkna upp varje komprimeringsdirektiv: serverns fil, eventuella pushade alternativ, klientspecifika filer och klientprofilen. comp-lzo på servern behöver samma ord på klienten, och adaptive är det gamla standardvärdet som det nakna alternativet vanligtvis betyder på äldre byggen. En routers GUI-omkopplare märkt LZO eller komprimering skriver samma alternativ, så ställ in den så att den matchar i stället för att blanda algoritmer. Anta inte att ett liknande namn är kompatibelt.

Om komprimering inte önskas, ta bort den medvetet från båda ändarna. allow-compression no på servern avvisar komprimerade paket, men först efter att klienterna slutat erbjuda dem; att tillämpa det medan en klient fortfarande pushar komprimering återskapar avvikelsen i den andra riktningen.

Kontrollera pushningen och enhetstypen

En server kan pusha ett komprimeringsdirektiv från sin huvudfil eller från en klientspecifik fil, och en klient kan släppa pushade alternativ med pull-filter. Anslut en klient vid detaljrikedom 4, läs vad servern meddelade mot vad klienten accepterade, och bekräfta sedan att inget filter tog bort det. Om båda sidor nu är överens och felet kvarstår, titta på enhetstypen: dev tap i den ena änden och dev tun i den andra kan inte utbyta ramar, och kärnan avvisar skrivningen på samma sätt.

En bryggad TAP-distribution kräver en riktig brygga på servern, inte bara ett annat enhetsnamn. Att byta namn på ett gränssnitt till tap0 utan att lägga till det i en brygga ger en enhet som accepterar skrivningen och inte kommer någonstans.

Verifiera sedan med en klient och en destination: pinga serverns tunneladress, sedan en värd på dess LAN. Det första bevisar datakanalen och det andra vidarebefordran.