Netgear OpenVPN: TUN e TAP escoitan en portos distintos

Un teléfono conecta á VPN do router sen queixa, e un portátil que usa un perfil da mesma páxina de descarga esgota o tempo. Nada dos certificados cambiou entre eses dous intentos, porque o portátil nunca chegou ao punto en que os certificados importan. O router publica escoitas separadas para TUN e TAP, e un perfil que funcione ten que escoller a que corresponde ao seu propio tipo de dispositivo.

Decidir cal dos tres fallos candidatos perseguir é todo o traballo aquí: o porto, o tipo de dispositivo ou a negociación do cifrado da canle de datos.

Tres cousas que teñen que coincidir

O tipo de dispositivo, a liña de interface do perfil e o porto de escoita forman unha soa elección, non tres. Un perfil que declara dev tun e apunta á escoita TAP non pode completar a sesión, e o contrario falla igual. Para o seu modelo e firmware, lea o porto na propia páxina VPN do router e non nunha guía, porque os números cambian entre compilacións. Anote o modelo e a versión de firmware xunto a ese número para que a seguinte persoa poida verificalo.

Os informes de campo mencionan un par como 12973 para TUN e 12974 para TAP nun firmware, e un número distinto noutro. Léaos como proba de que as compilacións difiren, non como constantes que copiar. O perfil necesita entón o nome de host axeitado á distancia: o nome DNS dinámico do router en lugar dun enderezo WAN que cambiará.

Despois de corrixir o porto e a liña de interface, o perfil parece unha configuración de cliente normal cunha liña remote e unha liña dev. Se as dúas non coinciden, ningunha cantidade de reintentos produce unha sesión.

Lea o rexistro na orde en que se imprime

Un cliente OpenVPN informa dos eventos na orde en que ocorren, así que a última liña antes do silencio identifica a capa que hai que inspeccionar. Cando a execución remata en TLS Error: TLS key negotiation failed, ou simplemente agarda unha primeira resposta e réndese, a comparación de certificados nunca ocorreu. Iso apunta á accesibilidade, á escoita ou a un porto que non ten nada detrás. Nada diso se repara substituíndo o ficheiro CA.

Unha execución que chega a VERIFY OK e logo falla está noutro sitio por completo, coas súas propias causas. Separar eses dous desenlaces antes de tocar ficheiros evita o clásico rodeo polos paquetes de certificados que nunca se consultaron. Unha vez completado o handshake pero sen que o túnel suba, mire a negociación do cifrado en lugar da accesibilidade.

Engada a lista de cifrados que espera un cliente moderno

Os clientes OpenVPN recentes rexeitan os valores predeterminados antigos que o firmware doméstico segue ofrecendo, e o síntoma é un fallo de negociación xusto despois dun handshake correcto. A solución é unha liña de perfil que nomea o que o cliente aceptará: axuste data-ciphers a AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 e AES-128-CBC nesa orde. Calquera algoritmo que o router non implemente simplemente nunca se selecciona, así que unha lista máis longa non custa nada máis que unha negociación algo máis longa.

Enumerar cifrados non lle ensina ao router un que non ten. Se a negociación segue fallando, comprobe se a páxina do router ten a súa propia configuración de cifrado e se esa configuración inclúe polo menos unha entrada que o cliente acepte. Dúas listas sen membro común producen exactamente o mesmo fallo que un porto equivocado, e por iso os dous extremos merecen unha ollada.

Importe unha vez en lugar de editar copias a man

Importar o ficheiro corrixido en NetworkManager evita un cartafol cheo de perfís lixeiramente distintos: nmcli connection import type openvpn file client.ovpn, e despois actíveo polo nome. Conserve o perfil importado como a única copia que edita e elimine os duplicados que se acumulan de descargas repetidas.

Despois probe desde fóra da LAN. Conectarse desde a mesma rede demostra moi pouco, porque o tráfico pode non atravesar o túnel en absoluto. Confirme que unha petición sae realmente polo router, non só que o cliente mostra un estado conectado.

Decida que facer cos avisos

O firmware doméstico adoita acuñar a súa propia autoridade de certificación, e os clientes quéixanse da verificación de maneiras que o firmware non pode suprimir. Xulgue se esa queixa importa para o que protexe en lugar de tratar cada aviso como fatal, e non desactive a verificación globalmente para silenciar unha soa mensaxe. Un aviso que avaliou é un risco documentado; unha configuración de verificación que desactivou non o está.

Cando o firmware non ofrece ningunha forma admitida de corrixir un aviso que si importa, esa carencia aconsella aloxar a VPN noutro sitio. Escoller entre reparar o perfil, aceptar o aviso e trasladar o punto final é unha decisión sobre canto confía nese certificado. Tómema deliberadamente e anote que opción escolleu, en lugar de ir premendo diálogos ata que a icona se poña verde.