I client VPN raggiungono il server ma non la LAN: quale correzione?

Il client esegue il ping dell'indirizzo del tunnel del server OpenVPN e riceve risposta, poi prova un host della LAN del server e non ottiene nulla. Questa divisione restringe molto il guasto: il tunnel è attivo, l'inoltro probabilmente funziona e la risposta esce da una porta che non riporta indietro. Esistono tre correzioni, e quella giusta dipende da ciò che controllate e da ciò a cui siete disposti a rinunciare. Rispondete alle tre domande qui sotto in ordine e la scelta smette di essere questione di gusti.

Prima confermate quale direzione è rotta

La richiesta arriva sull'interfaccia del tunnel con un indirizzo sorgente del pool VPN. Il server la inoltra all'host della LAN, e quell'host risponde al gateway indicato dalla propria tabella, di solito il router della LAN. Se il router non ha una rotta verso il pool, la risposta muore lì o vaga verso Internet.

Provate entrambe le macchine prima di modificarne una. Chiedete al server quale rotta prenderebbe la sua tabella verso un client; chiedete all'host della LAN come raggiungerebbe lo stesso indirizzo. La prima ricerca di solito punta al tunnel e la seconda al router della LAN, e quella differenza è il guasto in una riga. Due ricerche costano meno di un audit del firewall e fissano la direzione del problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Se l'host della LAN punta già al server VPN, il problema è una regola del firewall o un limite MTU, non un percorso di ritorno mancante. Non aggiungete una rotta per correggere un filtro.

Domanda uno: potete modificare il router della LAN remota?

Quando il router della LAN è vostro, una rotta statica verso il pool VPN con l'indirizzo LAN del server VPN come next hop è la risposta pulita. Mantiene intatti gli indirizzi sorgente dei client, cosa che conta quando gli host della LAN registrano, filtrano o limitano la banda per indirizzo. Non richiede alcuna traduzione sul server, così il tunnel resta un percorso di puro routing. L'obbligo che crea è documentale, perché pool, rotta e configurazione del server devono concordare.

Fallisce in silenzio il giorno in cui qualcuno cambia il pool. Scrivete il valore una volta e trattate una modifica in uno dei tre punti come una modifica a tutti e tre.

Un NAS o uno switch di livello 3 che ospita il servizio richiede la stessa rotta, a meno che non invii tutto attraverso un router che la possiede. Controllate il dispositivo che termina la sottorete, non solo quello rivolto a Internet. Le reti piccole hanno spesso tre apparati con un'opinione sul routing.

Domanda due: la LAN può smettere di vedere gli indirizzi dei client?

Quando il router è di qualcun altro, la traduzione sul server VPN non richiede collaborazione. L'host della LAN vede l'indirizzo LAN del server, gli risponde e il server ritraduce. Ecco perché gli appliance e i ruoli di accesso remoto basati su NAT si comportano così.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Il costo è l'attribuzione: gli indirizzi per client spariscono dai log della LAN. Qualsiasi allowlist sull'host della LAN deve quindi nominare il server al posto del pool.

Scegliete la traduzione quando la collaborazione non è disponibile, non quando è soltanto scomoda. Nasconde il client a ogni indagine futura, comprese quelle in cui dovete sapere quale portatile ha aperto una connessione. Può anche rompere protocolli che incorporano indirizzi nel payload, perché la traduzione vive nell'intestazione. Nessuna delle due opzioni è più avanzata; rispondono a domande diverse sulla proprietà.

Domanda tre: il server stesso è client di un altro tunnel?

Immaginate l'altra topologia: il server VPN compone anche un provider commerciale, quindi ha due tunnel e due insiemi di indirizzi. Il traffico che inoltra per i propri client esce dal provider, che non instraderà le risposte verso gli indirizzi del pool. Ecco perché le risposte svaniscono anche se entrambi i tunnel sono sani.

La correzione è mascherare anche il tunnel in uscita, così il provider vede solo l'indirizzo del tunnel del server. La direzione inversa richiede una regola propria, perché il server che avvia una connessione verso uno dei suoi client è un flusso diverso. Senza quella regola il client risponde a un indirizzo che non può instradare. Mettete la regola stretta prima di qualsiasi mascheramento ampio, così vince la traduzione specifica.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Gli host multi-homed aggiungono un guasto correlato che dal client sembra identico. La risposta esce dall'interfaccia con metrica più bassa perché l'indirizzo sorgente è stato scelto da un'altra tabella. Controllate il percorso di ritorno con una ricerca invece di presumere che quello di andata lo implichi.

Poi verificate entrambe le direzioni e entrambe le taglie

Dopo la modifica, fate ping dal client a un host della LAN e poi dall'host della LAN al client. La seconda direzione è quella che si salta, ed è quella che rivela una regola di traduzione incompleta. Registrate entrambi i risultati con marca temporale, così una regressione successiva è confrontabile.

Poi spostate dati reali, perché un ping piccolo che riesce mentre un trasferimento grande si blocca è un sintomo MTU. Quel guasto appare subito dopo che vi siete complimentati per aver corretto la rotta.

Infine, riprovate dopo un riavvio. I comandi di rotta e firewall a caldo non sopravvivono, e una correzione che svanisce al riavvio successivo sarà diagnosticata di nuovo da qualcuno con meno contesto. Rendete la modifica persistente come il vostro sistema già fa, poi riavviate una volta di proposito.