Netgear OpenVPN: TUN e TAP ascoltano su porte diverse

Un telefono si connette alla VPN del router senza lamentele, mentre un portatile che usa un profilo dalla stessa pagina di download va in timeout. Nulla dei certificati è cambiato tra questi due tentativi, perché il portatile non è mai arrivato al punto in cui i certificati contano. Il router pubblica listener separati per TUN e TAP, e un profilo funzionante deve scegliere quello che appartiene al proprio tipo di dispositivo.

Decidere quale dei tre guasti candidati inseguire è tutto il lavoro qui: la porta, il tipo di dispositivo o la negoziazione della cifratura del canale dati.

Tre cose che devono coincidere

Il tipo di dispositivo, la riga di interfaccia del profilo e la porta di ascolto formano una sola scelta, non tre. Un profilo che dichiara dev tun e punta al listener TAP non può completare la sessione, e il contrario fallisce allo stesso modo. Per il vostro modello e firmware, leggete la porta dalla pagina VPN del router stesso invece che da una guida, perché i numeri cambiano tra le build. Annotate modello e versione del firmware accanto a quel numero, così la persona successiva può verificarlo.

I rapporti dal campo citano una coppia come 12973 per TUN e 12974 per TAP su un firmware, e un numero diverso su un altro. Leggeteli come prova che le build differiscono, non come costanti da copiare. Il profilo ha poi bisogno del nome host adatto alla distanza: il nome DNS dinamico del router invece di un indirizzo WAN che cambierà.

Dopo aver corretto la porta e la riga di interfaccia, il profilo sembra una normale configurazione client con una riga remote e una riga dev. Se le due non coincidono, nessuna quantità di tentativi produce una sessione.

Leggete il registro nell'ordine in cui viene stampato

Un client OpenVPN riporta gli eventi nell'ordine in cui accadono, quindi l'ultima riga prima del silenzio identifica il livello da ispezionare. Quando l'esecuzione termina su TLS Error: TLS key negotiation failed, o semplicemente attende una prima risposta e si arrende, il confronto dei certificati non è mai avvenuto. Questo indica raggiungibilità, il listener o una porta che non ha nulla dietro. Nulla di ciò si ripara sostituendo il file CA.

Un'esecuzione che arriva a VERIFY OK e poi fallisce sta altrove, con le proprie cause. Separare questi due esiti prima di toccare i file evita il classico giro attraverso bundle di certificati che non sono mai stati consultati. Una volta completato l'handshake ma senza che il tunnel salga, guardate la negoziazione della cifratura invece della raggiungibilità.

Aggiungete la lista di cifrature che un client moderno si aspetta

I client OpenVPN recenti rifiutano i vecchi valori predefiniti che il firmware domestico offre ancora, e il sintomo è un fallimento della negoziazione subito dopo un handshake riuscito. La correzione è una riga del profilo che nomina ciò che il client accetterà: impostate data-ciphers su AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 e AES-128-CBC in quest'ordine. Qualsiasi algoritmo che il router non implementa semplicemente non viene mai scelto, quindi una lista più lunga non costa nulla se non una negoziazione un po' più lunga.

Elencare le cifrature non insegna al router una che non ha. Se la negoziazione fallisce ancora, controllate se la pagina del router ha un'impostazione di cifratura propria e se questa include almeno una voce che il client accetta. Due liste senza membri comuni producono esattamente lo stesso fallimento di una porta sbagliata, ed è per questo che entrambe le estremità meritano uno sguardo.

Importate una volta invece di modificare copie a mano

Importare il file corretto in NetworkManager evita una cartella piena di profili leggermente diversi: nmcli connection import type openvpn file client.ovpn, poi attivatelo per nome. Conservate il profilo importato come l'unica copia che modificate, ed eliminate i duplicati che si accumulano con download ripetuti.

Poi provate dall'esterno della LAN. Connettervi dalla stessa rete dimostra molto poco, perché il traffico potrebbe non attraversare affatto il tunnel. Confermate che una richiesta esca davvero attraverso il router, non solo che il client mostri uno stato connesso.

Decidete cosa fare degli avvisi

Il firmware domestico di solito conia la propria autorità di certificazione, e i client si lamentano della verifica in modi che il firmware non può sopprimere. Valutate se quella lamentela conta per ciò che proteggete invece di trattare ogni avviso come fatale, e non disattivate la verifica a livello globale per mettere a tacere un solo messaggio. Un avviso che avete valutato è un rischio documentato; un'impostazione di verifica che avete disattivato non lo è.

Quando il firmware non offre alcun modo supportato per correggere un avviso che conta davvero, quella lacuna depone a favore di ospitare la VPN altrove. Scegliere tra riparare il profilo, accettare l'avviso e spostare l'endpoint è una decisione su quanto vi fidate di quel certificato. Prendetela deliberatamente e annotate quale opzione avete scelto, invece di cliccare tra le finestre finché l'icona non diventa verde.