TUN/TAP: argument no vàlid — desajust de l’emmarcat d’OpenVPN

El client s’autentica, el registre diu connectat i cap paquet travessa el túnel. El servidor acaba l’intent amb write to TUN/TAP: Invalid argument (code=22), que sembla una fallada del controlador i normalment no ho és. Als encaminadors i als servidors Linux petits, aquesta línia sovint vol dir que els dos extrems no es posen d’acord sobre com s’emmarquen els paquets de dades, així que el nucli rebutja el búfer desxifrat que li han lliurat. L’encaminament encara no s’ha provat en aquell punt.

Una taula d’encaminament correcta i un acord d’emmarcat trencat semblen iguals des del client: connectat, i res no funciona.

El túnel puja i res no el travessa

Els errors d’escriptura al dispositiu del túnel passen després del desxifrat i abans de l’encaminament. El dimoni desxifra un paquet, el lliura a la interfície, i la interfície el rebutja perquè el búfer no coincideix amb el que espera aquell dispositiu. El codi 22 és la resposta genèrica d’argument no vàlid, així que la informació útil és la capa: aquesta és la ruta de dades i no l’intercanvi de salutació. Si el trànsit ahir anava i avui s’atura sense cap canvi de configuració, sospiteu d’una actualització de paquet o de firmware que hagi mogut un valor per defecte abans de sospitar de la xarxa.

Llegiu el registre al voltant de la configuració del canal de dades en lloc del primer error. El mode de compressió negociat, el tipus dev i les opcions empenyudes apareixen tots amb més verbositat, i us diuen quin dels tres desajustos teniu.

La compressió és emmarcat, no amplada de banda

Amb la compressió activada, cada paquet de dades porta una capçalera que descriu com s’ha codificat, i els dos extrems han de coincidir en aquesta capçalera. Un servidor que encara porta comp-lzo d’una configuració d’exemple antiga, aparellat amb un client que no té cap línia de compressió, produeix exactament aquest error: el servidor espera una capçalera que el client mai va escriure. Barrejar comp-lzo amb compress lz4-v2 falla de la mateixa manera, ja que els algorismes difereixen tot i que tots dos es diuen compressió. L’opció és un contracte d’emmarcat i no una funció d’amplada de banda en els enllaços moderns.

El comportament de les versions afegeix un parany. La sèrie 2.5 va començar a emetre avisos d’obsolescència per a les opcions de compressió, i 2.6 traça una línia entre rebutjar els paquets comprimits i simplement deixar les dades sense comprimir. Per tant, una actualització de firmware de l’encaminador pot canviar l’acord efectiu sense que ningú editi el túnel.

Alineeu els dos extrems o traieu-ho dels dos

Enumerem cada directiva de compressió: el fitxer del servidor, qualsevol opció empenyuda, els fitxers específics del client i el perfil del client. comp-lzo al servidor necessita la mateixa paraula al client, i adaptive és el valor per defecte llegat que l’opció nua sol significar en compilacions antigues. L’interruptor de la GUI de l’encaminador etiquetat LZO o compressió escriu aquesta mateixa opció, així que poseu-lo perquè coincideixi en lloc de barrejar algorismes. No assumiu que un nom d’aspecte similar sigui compatible.

Si no voleu compressió, traieu-la deliberadament dels dos extrems. allow-compression no al servidor rebutja els paquets comprimits, però només quan els clients han deixat d’oferir-los; aplicar-ho mentre un client encara empeny compressió torna a crear el desajust en l’altra direcció.

Comproveu l’empenta i el tipus de dispositiu

Un servidor pot empènyer una directiva de compressió des del seu fitxer principal o des d’un fitxer específic del client, i un client pot descartar les opcions empenyudes amb pull-filter. Connecteu un client amb verbositat 4, llegiu què ha anunciat el servidor enfront del que ha acceptat el client, i després confirmeu que cap filtre ho ha eliminat. Si els dos costats ara coincideixen i l’error continua, mireu el tipus de dispositiu: dev tap en un extrem i dev tun a l’altre no poden intercanviar trames, i el nucli rebutja l’escriptura de la mateixa manera.

Un desplegament TAP amb pont necessita un pont real al servidor, no només un nom de dispositiu diferent. Reanomenar una interfície a tap0 sense afegir-la a un pont produeix un dispositiu que accepta l’escriptura i no va enlloc.

Després verifiqueu amb un client i una destinació: feu ping a l’adreça del túnel del servidor, i després a un amfitrió de la seva LAN. El primer demostra el canal de dades i el segon, el reenviament.