Netgear OpenVPN: TUN i TAP escolten en ports diferents

Un telèfon es connecta a la VPN del router sense cap queixa, i un portàtil que fa servir un perfil de la mateixa pàgina de baixada esgota el temps. Res dels certificats no havia canviat entre aquests dos intents, perquè el portàtil mai va arribar al punt on els certificats importen. El router publica oients separats per a TUN i TAP, i un perfil que funcioni ha de triar el que correspon al seu propi tipus de dispositiu.

Decidir quin dels tres errors candidats cal perseguir és tota la feina aquí: el port, el tipus de dispositiu o la negociació del xifratge del canal de dades.

Tres coses que han de coincidir

El tipus de dispositiu, la línia d'interfície del perfil i el port de l'oient formen una sola tria, no tres. Un perfil que declara dev tun i apunta a l'oient TAP no pot completar la sessió, i el contrari falla de manera idèntica. Per al vostre model i firmware, llegiu el port de la pròpia pàgina VPN del router i no d'una guia, perquè els números canvien entre versions. Escriviu el model i la versió del firmware al costat d'aquest número perquè la propera persona ho pugui verificar.

Els informes de camp esmenten una parella com 12973 per a TUN i 12974 per a TAP en un firmware, i un número diferent en un altre. Llegiu-los com a prova que les versions difereixen, no com a constants per copiar. El perfil necessita llavors el nom d'amfitrió adequat a la distància: el nom DNS dinàmic del router en comptes d'una adreça WAN que canviarà.

Després de corregir el port i la línia d'interfície, el perfil sembla una configuració de client normal amb una línia remote i una línia dev. Si les dues no coincideixen, cap quantitat de reintents produeix una sessió.

Llegiu el registre en l'ordre en què s'imprimeix

Un client OpenVPN informa dels esdeveniments en l'ordre en què passen, així que l'última línia abans del silenci identifica la capa que cal inspeccionar. Quan l'execució acaba a TLS Error: TLS key negotiation failed, o simplement espera una primera resposta i es rendeix, la comparació de certificats mai no va passar. Això apunta a l'abastabilitat, a l'oient o a un port que no té res al darrere. Cap d'aquests no es repara substituint el fitxer CA.

Una execució que arriba a VERIFY OK i després falla es troba en un altre lloc del tot, amb les seves pròpies causes. Separar aquests dos resultats abans de tocar fitxers evita el desviament clàssic pels paquets de certificats que mai no s'han consultat. Un cop l'apretada de mans s'ha completat però el túnel no arrenca, mireu la negociació del xifratge en lloc de l'abastabilitat.

Afegiu la llista de xifratges que un client modern espera

Els clients OpenVPN recents rebutgen els valors per defecte antics que el firmware domèstic encara ofereix, i el símptoma és una fallada de negociació just després d'una apretada de mans correcta. La solució és una línia del perfil que nomena què acceptarà el client: poseu data-ciphers a AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 i AES-128-CBC en aquest ordre. Qualsevol algorisme que el router no implementi simplement no s'escollirà mai, així que una llista més llarga no costa res més que una negociació una mica més llarga.

Enumerar xifratges no ensenya al router un que no tingui. Si la negociació encara falla, comproveu si la pàgina del router té una configuració de xifratge pròpia i si aquesta configuració inclou almenys una entrada que el client accepti. Dues llistes sense cap membre comú produeixen exactament la mateixa fallada que un port equivocat, i per això els dos extrems mereixen una mirada.

Importeu un cop en lloc d'editar còpies a mà

Importar el fitxer corregit a NetworkManager evita una carpeta plena de perfils lleugerament diferents: nmcli connection import type openvpn file client.ovpn, i després activeu-lo pel nom. Manteniu el perfil importat com l'única còpia que editeu, i suprimiu els duplicats que s'acumulen amb baixades repetides.

A continuació proveu-ho des de fora de la LAN. Connectar-se des de la mateixa xarxa demostra molt poc, perquè el trànsit potser no travessa mai el túnel. Confirmeu que una petició surt realment pel router, no només que el client mostra un estat connectat.

Decidiu què fer amb els avisos

El firmware domèstic normalment encunya la seva pròpia autoritat de certificació, i els clients es queixen de la verificació de maneres que el firmware no pot suprimir. Jutgeu si aquesta queixa importa per a allò que protegiu en lloc de tractar cada avís com a fatal, i no desactiveu la verificació globalment per silenciar un sol missatge. Un avís que heu avaluat és un risc documentat; una configuració de verificació que heu desactivat no està documentada.

Quan el firmware no ofereix cap manera suportada de corregir un avís que sí que importa, aquesta mancança afavoreix allotjar la VPN en un altre lloc. Triar entre reparar el perfil, acceptar l'avís i traslladar el punt final és una decisió sobre quant us fieu d'aquell certificat. Preneu-la deliberadament i anoteu quina opció heu triat, en lloc de clicar pels diàlegs fins que la icona es torni verda.