TUN/TAP: argumento non válido — desaxuste do entramado de OpenVPN

O cliente autentícase, o rexistro di conectado e ningún paquete cruza o túnel. O servidor remata o intento con write to TUN/TAP: Invalid argument (code=22), que parece unha falla do controlador e normalmente non o é. En routers e servidores Linux pequenos, esa liña adoita significar que os dous extremos non se poñen de acordo sobre como se entraman os paquetes de datos, así que o núcleo rexeita o búfer descifrado que se lle entregou. O enrutamento aínda non se probou nese punto.

Unha táboa de rutas correcta e un acordo de entramado roto vense iguais desde o cliente: conectado, e nada funciona.

O túnel sobe e nada o cruza

Os erros de escritura no dispositivo do túnel ocorren despois do descifrado e antes do enrutamento. O daemon descifra un paquete, entrégao á interface, e a interface rexéitao porque o búfer non coincide co que espera ese dispositivo. O código 22 é a resposta xenérica de argumento non válido, así que a información útil é a capa: esta é a ruta de datos e non o handshake. Se o tráfico onte funcionaba e hoxe parou sen ningún cambio de configuración, sospeite dunha actualización de paquete ou firmware que moveu un valor predeterminado antes de sospeitar da rede.

Lea o rexistro arredor da configuración da canle de datos en lugar do primeiro erro. O modo de compresión negociado, o tipo dev e as opcións empurradas aparecen todos con maior verbosidade, e dinlle cal dos tres desaxustes ten.

A compresión é entramado, non ancho de banda

Coa compresión activada, cada paquete de datos leva unha cabeceira que describe como se codificou, e ambos extremos deben poñerse de acordo sobre esa cabeceira. Un servidor que aínda leva comp-lzo dunha configuración de exemplo antiga, emparellado cun cliente que non ten liña de compresión, produce exactamente este erro: o servidor espera unha cabeceira que o cliente nunca escribiu. Mesturar comp-lzo con compress lz4-v2 falla do mesmo xeito, xa que os algoritmos difiren aínda que ambos se chamen compresión. A opción é un contrato de entramado e non unha función de ancho de banda nos enlaces modernos.

O comportamento das versións engade unha trampa. A serie 2.5 comezou a emitir avisos de obsolescencia para as opcións de compresión, e 2.6 traza unha liña entre rexeitar os paquetes comprimidos e simplemente deixar os datos sen comprimir. Por tanto, unha actualización de firmware do router pode cambiar o acordo efectivo sen que ninguén edite o túnel.

Aliñe ambos extremos ou quítoo dos dous

Enumere cada directiva de compresión: o ficheiro do servidor, calquera opción empurrada, os ficheiros específicos do cliente e o perfil do cliente. comp-lzo no servidor necesita a mesma palabra no cliente, e adaptive é o valor predeterminado herdado que a opción espida adoita significar en compilacións antigas. O interruptor da GUI do router etiquetado LZO ou compresión escribe esa mesma opción, así que axústeo para que coincida en lugar de mesturar algoritmos. Non asuma que un nome de aspecto similar sexa compatible.

Se non se desexa a compresión, elimín ea deliberadamente de ambos extremos. allow-compression no no servidor rexeita os paquetes comprimidos, pero só cando os clientes deixaron de ofrecelos; aplicalo mentres un cliente aínda empurra compresión recrea o desaxuste na outra dirección.

Comprobe o empurrón e o tipo de dispositivo

Un servidor pode empurrar unha directiva de compresión desde o seu ficheiro principal ou desde un ficheiro específico do cliente, e un cliente pode descartar as opcións empurradas con pull-filter. Conecte un cliente con verbosidade 4, lea o que anunciou o servidor fronte ao que aceptou o cliente, e despois confirme que ningún filtro o eliminou. Se ambos os lados agora coinciden e o erro persiste, mire o tipo de dispositivo: dev tap nun extremo e dev tun no outro non poden intercambiar tramas, e o núcleo rexeita a escritura do mesmo xeito.

Unha implantación de TAP con ponte necesita unha ponte real no servidor, non só un nome de dispositivo diferente. Renomear unha interface a tap0 sen engadila a unha ponte produce un dispositivo que acepta a escritura e non vai a ningures.

Despois verifique cun cliente e un destino: faga ping ao enderezo do túnel do servidor, despois a un host na súa LAN. O primeiro demostra a canle de datos e o segundo o reenvío.