Router LAN e client VPN: due dispositivi, due tabelle di routing

Due dispositivi inoltrano il pacchetto e ciascuno tiene la propria tabella. Il router LAN sa che il prefisso remoto appartiene al client VPN, e il client VPN sa come raggiungere quel prefisso attraverso il suo tunnel. Configura solo la prima tabella e il pacchetto arriva a una macchina che non ha alcuna rotta corrispondente, quindi esce di nuovo dalla rotta predefinita. È tutto il guasto, e dal lato LAN sembra un loop di routing, perché quasi lo è.

Disegna i due hop prima di toccare una rotta

Prendi una disposizione illustrativa: host della LAN su 192.168.50.0/24, il router ordinario su 192.168.50.1, un client dedicato su 192.168.50.15 e una LAN remota su 10.60.0.0/24 raggiungibile solo attraverso il tunnel che quel client mantiene. Nessuno dei due intervalli privati si sovrappone all’altro, e il tunnel ha il suo piano di indirizzamento.

Entrambi gli intervalli privati contano perché decidono quale dispositivo può rispondere. Il lato remoto vedrà arrivare il pacchetto dall’indirizzo di tunnel del client, e la sua risposta deve trovare un percorso di ritorno a 192.168.50.0/24. Se è configurata solo la direzione in uscita, la richiesta può funzionare mentre la risposta scompare.

Passo 1: punta il router al client, non al tunnel

Sul router LAN, aggiungi una rotta di destinazione il cui next hop è l’indirizzo LAN del client:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Quel record dice «consegnalo alla macchina che sa fare tunnel». Non dice nulla su come viene costruito il tunnel e non sostituisce la rotta propria del client. Su un router gestito l’equivalente vive nella pagina delle rotte statiche del dispositivo; su un router Linux appartiene alla configurazione dell’interfaccia che possiede la LAN, non a una shell che chiuderai.

Controlla la risposta del secondo comando. Se riporta il client come gateway e l’interfaccia LAN come device, il primo hop è corretto e il lavoro restante è sull’altra macchina.

Passo 2: dai al client una rotta propria dal lato tunnel

Il client ora riceve un pacchetto per 10.60.0.0/24 e consulta la propria tabella. Se la sua configurazione di tunnel ha installato una rotta per quel prefisso, il pacchetto prosegue cifrato. Se non l’ha fatto, il pacchetto corrisponde alla predefinita ordinaria e torna a 192.168.50.1, che lo rimanda al client.

Guarda prima di aggiungere qualsiasi cosa:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Una rotta di prefisso assente in tutte le tabelle è il riscontro che cerchi. Aggiungila tramite la configurazione propria del tunnel, così la prossima riconnessione la reinstalla; una ip route add manuale scompare con la sessione e fa tornare il guasto nel momento meno opportuno. Il next hop è l’interfaccia di tunnel o l’indirizzo che la VPN assegna come peer, a seconda del client, e l’indirizzo del peer dovrebbe venire dal profilo attuale e non da una nota vecchia.

Il loop, quando accade, non è infinito in pratica: il TTL scende a ogni passaggio e il pacchetto muore con un messaggio di tempo superato. Per questo un traceroute ripetuto può suggerire un ciclo mentre un client che semplicemente non inoltra lascia cadere lo stesso pacchetto in silenzio.

Passo 3: consenti l’inoltro e scegli il percorso di ritorno

Ricevere e inoltrare sono permessi diversi. net.ipv4.ip_forward=1 sul client consente il transito a livello di kernel, e una regola del firewall deve comunque consentirlo tra l’interfaccia LAN e il tunnel. Una regola che consente l’accesso alla pagina di gestione del client non consentirà il transito verso la LAN remota, e la distinzione è facile da mancare quando lo stesso host risponde ai ping in locale.

Il lato remoto ha il problema speculare. Deve sapere che 192.168.50.0/24 è raggiungibile attraverso questo client autenticato. Con OpenVPN questo di solito significa una rotta per client spinta dalla configurazione del server, o un file specifico del client sul server che dichiara la LAN dietro il client. Senza di esso, la LAN remota o scarta la risposta o la invia al proprio gateway predefinito, cioè a internet.

La traduzione della sorgente è l’alternativa quando il prefisso della LAN non può essere annunciato. Una regola masquerade con ambito sul client riscrive la sorgente verso l’indirizzo del tunnel, e le risposte tornano allora naturalmente. Nasconde anche quale host della LAN ha fatto la richiesta, e da sola non consente al lato remoto di avviare connessioni verso l’interno. Scegli questo compromesso deliberatamente invece di aggiungere un masquerade generale e scoprire l’effetto collaterale più tardi.

Passo 4: rendi persistenti entrambe le decisioni, poi prova il percorso reale

Ogni rotta ha un proprietario, e il proprietario è la configurazione che si rigenera all’avvio o alla riconnessione. Sul router può essere una voce di rotta statica; sul client può essere il profilo VPN, NetworkManager o systemd-networkd. Verifica riconnettendo il tunnel e riavviando il client, poi rileggi la tabella invece di fidarti della modifica.

Mantieni intatta la rotta predefinita che porta la connessione esterna del tunnel. Sostituirla per «semplificare» la configurazione rompe il percorso cifrato prima che qualsiasi traffico interno possa usarlo, e il sintomo è un tunnel che non si ristabilisce mai dopo la modifica.

Prova da un host LAN ordinario, non dal client, perché una richiesta originata sul client non esercita mai il primo hop del router. Recupera un servizio che esiste solo sulla LAN remota e conferma il corpo della risposta, poi controlla i contatori o i log del client per vedere il transito. Un traceroute interno che mostra hop privati dimostra l’inoltro, non la cifratura: il percorso esterno è un’osservazione separata, e solo i contatori dell’interfaccia del tunnel mostrano cosa è uscito attraverso di esso.