Masquerade o routing per policy: traffico LAN attraverso un gateway VPN

Mettere un’intera LAN dietro un tunnel VPN è la parte facile; decidere come il lato remoto vede quei client non lo è. Il masquerade riscrive ogni sorgente della LAN sull’indirizzo del tunnel del gateway, così l’estremità remota risponde a un solo peer. Il routing per policy conserva gli indirizzi originali e richiede che l’estremità remota sappia come raggiungerli. Nessuno dei due è predefinito; la scelta deriva da chi possiede il lato remoto e se conta l’identità per dispositivo.

I due progetti promettono cose diverse

Il masquerade riduce la LAN a un solo host visibile: il gateway. La rete remota risponde a quell’unico indirizzo, e il gateway traduce le risposte verso il client che ha avviato il flusso. Sul lato remoto non serve alcuna rotta ai tuoi prefissi privati, ed è per questo che questo progetto sopravvive a un provider che rifiuta di trasportarli. Il gateway diventa anche la sorgente di ogni connessione, quindi il lato remoto non può distinguere due client.

Il routing per policy mantiene intatto l’indirizzo di ogni client. La rete remota vede la sorgente reale e può registrarla, applicare una regola per host o inviare la risposta direttamente a quell’indirizzo. Questa visibilità è tutto il punto, e comporta un obbligo: il lato remoto deve avere una rotta per il prefisso della LAN che torni indietro attraverso il tunnel. Pianifica quella rotta prima di abilitare la regola, perché il tunnel salirà comunque e mancheranno solo le risposte.

Le modalità di guasto differiscono quanto le promesse. Una regola di masquerade assente produce pacchetti che escono con sorgenti private e non tornano mai. Una rotta di ritorno assente produce lo stesso sintomo nel routing per policy, ma la correzione spetta al router remoto, non al gateway.

Masquerade: un solo peer sul lato remoto

Il percorso del masquerade ha un ordine che conta. L’inoltro deve essere attivo prima che qualsiasi regola NAT serva a qualcosa, la tabella dei filtri deve consentire il transito in entrambe le direzioni, e solo allora la traduzione si applica sull’interfaccia del tunnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

I client hanno ancora bisogno di un percorso verso il gateway. O il gateway è il loro router predefinito, oppure portano una rotta specifica per il prefisso remoto; se un router separato resta il predefinito, quel router necessita di una rotta statica per le destinazioni del tunnel, altrimenti il pacchetto va al salto sbagliato prima che il gateway lo veda.

Il DNS è una decisione a parte. Un resolver sul lato remoto risponde solo se la sua risposta può tornare al client. Con il masquerade la query sembra provenire dal gateway, quindi il percorso di ritorno del resolver è già soddisfatto; con il routing per policy il resolver necessita della stessa rotta di ritorno di qualsiasi altro servizio remoto.

Routing per policy: conserva la sorgente, aggiungi una rotta di ritorno

Il routing per policy parte da una tabella e da una regola che la seleziona. Il traffico che entra dall’interfaccia della LAN viene inviato a una tabella dedicata, e quella tabella porta una rotta predefinita attraverso il tunnel. La tabella principale resta intatta, quindi il traffico originato dal gateway stesso può seguire un altro percorso.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Il lato remoto deve poi instradare il prefisso della LAN indietro attraverso il tunnel. È una configurazione sul router remoto, non su questo gateway. Il gateway deve anche accettare risposte che arrivano su un’interfaccia diversa da quella che la tabella principale prevedrebbe; il filtraggio permissivo del percorso inverso (rp_filter impostato a 2) è la regolazione abituale quando la modalità rigorosa scarta quei pacchetti.

Quando due tunnel sono attivi, etichetta ogni flusso all’ingresso e lascia che l’etichetta scelga la tabella. Una regola che guarda solo l’interfaccia di ingresso invia il traffico di entrambi i tunnel alla stessa tabella, così il secondo tunnel ruba flussi al primo. Prova quell’etichetta con una connessione che sopravvive a una riconnessione, perché è allora che una policy mista si manifesta.

Decidi in base alla proprietà e a ciò che il lato remoto registra

Se il tunnel termina presso un provider, usa il masquerade. Quell’operatore non instraderà i tuoi intervalli LAN privati e non ha motivo di distinguere client individuali dietro il tuo gateway. Un solo peer visibile è l’unico modello che la sua policy supporta, quindi dagli questo e tieni la traduzione al tuo bordo. Il provider vede un peer, che è esattamente ciò che la sua policy si aspetta, e i tuoi client ereditano quell’unica identità.

Se entrambe le estremità sono tue e i servizi remoti agiscono sugli indirizzi di sorgente, il routing per policy merita la sua rotta extra. Le regole del firewall, l’accesso per utente e i log di audit possono allora distinguere i client. Se il lato remoto ha bisogno solo di raggiungibilità, il masquerade è più semplice ed elimina un’intera classe di errori di rotta di ritorno.

I progetti ibridi sono normali: routing per policy dentro la tua rete, masquerade al bordo del provider. L’importante è annotare quale salto traduce e quale salto instrada, perché una regola NAT aggiunta per errore per un client nasconde la sorgente a ogni client della stessa catena.

Verifica da un client, poi da un secondo client

Esegui il test dove inizia il traffico. Controlla la rotta usata dall’host, osserva il pacchetto comparire sull’interfaccia del tunnel e ispeziona conntrack per la traduzione. Quella sequenza dimostra che il pacchetto ha preso il percorso previsto, non che è semplicemente arrivato da qualche parte.

Ripeti il test dopo una riconnessione. Una regola di masquerade che nomina l’interfaccia sopravvive a un nuovo indirizzo di tunnel; una regola che nomina il vecchio indirizzo no. Poi prova un secondo host della LAN, perché un progetto che funziona su una macchina spesso dipende dalla rotta di quella macchina e non dalla policy del gateway.

Annota il modello scelto, la sorgente tradotta o preservata e il proprietario della rotta di ritorno nelle note del gateway. Altrimenti la prossima persona che aggiunge un client o un tunnel tirerà a indovinare, e indovinare è il modo in cui una configurazione LAN-a-VPN funzionante diventa parziale.