OpenVPN a tunnel completo: aggiungere un’uscita internet lato server

Un client si autentica, riceve un indirizzo dal pool e raggiunge i servizi sull’host VPN, ma ogni destinazione pubblica va in timeout. Ecco che aspetto ha un tunnel senza uscita, e resta così finché quattro cose distinte non sono vere. Il client deve accettare una rotta predefinita, il server deve inoltrare, il firewall deve consentire il transito e le risposte hanno bisogno di un percorso di ritorno verso il pool. Tutti e quattro i guasti condividono un solo sintomo, quindi cambiate un elemento per tentativo e annotate il risultato.

Spingete la rotta predefinita e verificate cosa ha installato il client

La riga lato server è breve, e riguarda solo i client che accettano le opzioni spinte. La forma def1 installa due semi-rotte predefinite invece di eliminare la predefinita esistente, il che mantiene viva la connessione attuale e cattura comunque ogni destinazione.

push "redirect-gateway def1"

Dopo la riconnessione, leggete la tabella di routing del client invece di fidarvi del profilo. Su Linux le due voci /1 compaiono accanto alla predefinita originale, e Windows mostra la stessa coppia come 0.0.0.0/1 e 128.0.0.0/1. Un client che ignora le opzioni spinte, o uno configurato per rifiutarle, conserva la vecchia predefinita e non manda mai traffico internet nel tunnel. Risolvete questa questione prima di cambiare qualsiasi cosa sul server, perché nessuna regola lato server può compensare.

L’inoltro è un’impostazione del server, non del VPN

Leggete il flag di inoltro prima di toccare il routing. Uno zero lì significa che il kernel riceve il pacchetto del client e rifiuta di passarlo oltre, cosa che sembra esattamente un blocco del firewall dall’estremità remota. Impostate il valore tramite la directory di configurazione del sistema perché sopravviva a un riavvio.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Poi verificate che l’host stesso abbia una rotta funzionante verso l’uscita internet. Una richiesta dalla shell del server dimostra che il percorso a monte è utilizzabile e non dice assolutamente nulla sull’inoltro del pacchetto di un client, quindi trattatele come due test separati. Se il server non raggiunge la destinazione, nessuna quantità di configurazione dell’inoltro aiuterà.

Consentite esattamente il transito che volete, e nient’altro

I pacchetti inoltrati attraversano il percorso forward; il traffico indirizzato all’host VPN stesso attraversa input. Sono decisioni distinte, e aprire il percorso input non consente il transito attraverso la macchina. Confonderle è la ragione più comune per cui un firewall sembra consentire tutto mentre i client vanno ancora in timeout.

Una politica minima accetta nuove connessioni dal pool verso l’interfaccia di uscita e accetta le risposte che appartengono a flussi stabiliti. Mettetela nel proprietario del set di regole che usa la vostra distribuzione, invece di aggiungere una regola duplicata a ogni avvio; le regole duplicate si accumulano e i contatori smettono di significare qualcosa.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Portare ogni catena su accept fa passare il test e toglie la ragione per cui il firewall esiste. Mantenete l’ambito sul pool e sull’interfaccia di uscita, e lasciate in pace l’inoltro non correlato.

Date alle risposte un posto dove andare

Gli indirizzi del pool sono privati, quindi un server pubblico non può consegnare loro una risposta direttamente. O l’host VPN traduce l’indirizzo di origine in uscita, o un dispositivo a monte detiene una rotta di ritorno verso il pool.

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

Aggiungete esattamente uno strato di traduzione. Un secondo NAT più a monte nasconde il primo e rende entrambi i log quasi inutili quando qualcosa si rompe più tardi. Se un router a monte instrada già il pool al ritorno, aggiungere la traduzione sull’host è ridondante, e il percorso di ritorno dipende allora dalla configurazione di quel router e non dalla vostra.

Le istanze cloud aggiungono un’altra porta, perché alcune piattaforme scartano i pacchetti il cui indirizzo di origine non è quello dell’istanza, a meno che quel controllo non venga allentato. Quell’impostazione sta fuori dall’ospite ed è facile da dimenticare quando una macchina di test locale funziona.

Dimostratelo dal client, non dalla shell del server

Iniziate con una richiesta IPv4 numerica, poi una risoluzione di nome, poi l’applicazione. Un ping dimostra inoltro e traduzione;non dimostra nulla sulla risoluzione, perché le opzioni DNS hanno effetto solo quando l’integrazione del client le installa.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Annotate le modifiche e il passo di annullamento man mano, così la politica di uscita può essere annullata con una sola azione quando un test fallisce. Questa ricetta copre solo IPv4; inventariate IPv6 separatamente prima di affermare che il deployment trasporta tutto il traffico.