La VPN del router funziona, ma i client LAN non hanno internet

Lo stato dice che il tunnel è attivo, un browser sul router stesso carica le pagine, e ogni dispositivo dietro di esso va comunque in timeout. Questa combinazione restringe il problema a uno strato che la maggior parte delle guide VPN non menziona mai: il router non è l'unico host i cui pacchetti devono sopravvivere al tunnel. Il traffico generato localmente e quello inoltrato seguono percorsi diversi attraverso lo stesso apparato. Prova da un client e la differenza smette di essere teorica.

Leggi il guasto da un host LAN

Parti dal dispositivo che fallisce, perché una diagnosi eseguita sul router risponde a una domanda diversa. Verifica che il gateway predefinito del client sia questo router, annota il suo indirizzo di origine e la sottorete, poi guarda cosa esce dall'interfaccia tunnel del router.

Se l'indirizzo del client viene tradotto, il lato remoto vede l'indirizzo del tunnel e da lì tutto sembra sano mentre il client continua a fallire. Se non viene tradotto, il lato remoto deve conoscere una rotta verso la sottorete del client, e molti gateway non hanno una tale rotta per impostazione predefinita. In entrambi i casi il successo del router è irrilevante, perché i suoi pacchetti sono stati generati localmente e non hanno mai attraversato il percorso di inoltro.

Traffico locale e traffico inoltrato sono diversi

Linux e la maggior parte dei firmware dei router trattano i pacchetti originati dall'apparato in modo diverso da quelli che lo attraversano. La catena output vede il primo tipo, la catena forward vede il secondo, e una politica tarata sul traffico del router può lasciare l'inoltro intatto.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Controlla se l'inoltro è abilitato, poi leggi la catena forward invece di quella output. Una regola che consente la connessione esterna cifrata non è una regola che consente di inoltrare pacchetti decifrati, e confondere le due produce esattamente questo sintomo. Il tunnel attivo dimostra solo la prima.

Deve esistere anche il percorso di ritorno

La traduzione dell'origine decide se serve un percorso di ritorno. Con il masquerading sull'interfaccia tunnel, le risposte tornano all'indirizzo del tunnel e il router le ritraduce. Senza, il gateway remoto ha bisogno di una rotta esplicita verso la sottorete del client, e la sua politica deve consentire quella direzione.

Registra quale dei due progetti usa l'installazione prima di cambiare qualsiasi cosa, perché le riparazioni puntano in direzioni opposte. Aggiungere la traduzione nasconde una rotta di ritorno mancante e rompe le applicazioni che richiedono l'indirizzo di origine originale. Aggiungere una rotta di ritorno senza traduzione fallisce in silenzio quando il firewall remoto scarta l'origine sconosciuta. Scegline uno, documentalo e fai corrispondere l'altro lato.

Anche il DNS dei client rientra nella stessa verifica. Il resolver del router può rispondere mentre un client puntato su un altro server non ottiene nulla.

Verifica un flusso consentito e uno negato

Dopo la correzione, prova una nuova connessione da un client invece che da una sessione del router già esistente. Poi conferma che un segmento che non dovrebbe usare il tunnel continui a non usarlo.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Controlla l'indirizzo di origine osservato all'estremità remota, perché ti dice quale progetto è realmente in esecuzione. Verifica anche la risoluzione dei nomi oltre all'indirizzo, perché il comportamento del resolver è un percorso separato attraverso lo stesso apparato.

Mantieni le regole limitate alle reti client che richiedono il tunnel e resisti alla tentazione di disattivare il filtro di inoltro per far passare un test. Quel cambiamento ripara il test e rimuove il confine che il tunnel doveva fornire. Scrivi in un'unica nota l'indirizzo di origine, la decisione di traduzione e la rotta di ritorno, con la data.