VPN da sito a sito o accesso remoto: cosa collega ciascuno

Entrambe le soluzioni si chiamano VPN e risolvono problemi diversi. Un tunnel da sito a sito collega due gateway, così ogni host dietro di essi può raggiungere gli indirizzi consentiti dall’altra parte senza installare nulla. Un tunnel di accesso remoto collega singoli dispositivi a una rete, un client alla volta. Il confronto conta perché la maggior parte degli errori di distribuzione nasce dal configurare una soluzione aspettandosi il comportamento dell’altra, e il sintomo è di solito un timeout su un servizio che il tunnel ha effettivamente raggiunto.

Due soluzioni, due confini

Nessuna delle due soluzioni estende un dominio di broadcast LAN. I dispositivi dall’altra parte non compaiono in un elenco di scoperta locale, e aspettarsi che lo facciano è la prima ipotesi da abbandonare. I nomi DNS privati che pubblicate deliberatamente sono più prevedibili di qualsiasi protocollo di scoperta e sopravvivono a un cambio di fornitore.

Prendete 10.10.0.0/24 su un sito e 10.20.0.0/24 sull’altro. Il gateway A ha bisogno di una rotta o di un selettore di traffico che invii il prefisso 10.20.0.0/24 nel tunnel, e il gateway B ha bisogno della sua immagine speculare. Gli host di entrambi i lati usano quindi connettività IP ordinaria e non vengono mai a sapere che esiste un tunnel. Questa invisibilità è la funzionalità, ed è anche il motivo per cui i guasti sembrano errori di rete ordinari anziché errori del tunnel.

Basato su politica e basato su rotta non sono lo stesso tunnel

In una distribuzione IPsec basata su politica, i selettori di traffico negoziati definiscono esattamente quali coppie di origine e destinazione sono protette. Se compare una nuova sottorete dietro un gateway e nessun selettore la copre, il tunnel resta attivo e la nuova sottorete semplicemente non viene trasportata. In una soluzione basata su rotta, un’interfaccia riceve il traffico e la tabella di routing decide, il che rende l’aggiunta di un prefisso un cambio di routing e non una rinegoziazione del tunnel.

StrongSwan espone direttamente entrambe le viste, e leggerle insieme è il modo per capire quale modello avete davvero distribuito.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Un elenco di selettori che omette il prefisso che vi interessa spiega il guasto senza alcuna cattura di pacchetti, e una rotta che punta all’interfaccia sbagliata spiega il guasto speculare al ritorno. Leggete entrambi prima di rinegoziare qualcosa, perché un rinnovo di chiave non aggiungerà un selettore che non avete mai configurato.

Pianificate l’indirizzamento prima del tunnel

Gli intervalli sovrapposti sono l’errore di progettazione che non si può correggere con la configurazione. Se entrambi i siti usano 192.168.1.0/24, un host che ha bisogno di 192.168.1.50 ha due candidati e nessun modo di scegliere. Il tunnel si autenticherà, le associazioni di sicurezza si stabiliranno e la decisione di routing sarà comunque errata o ambigua.

Scegliete una di tre opzioni oneste: rinumerare un sito, tradurre l’intervallo sovrapposto al gateway in modo che ogni lato veda un prefisso distinto, oppure rinunciare al routing diretto per quegli host e pubblicare il servizio in un altro modo. Ciascuna ha un costo, e la prima è di solito la più economica su un orizzonte di due anni. Decidete prima che il tunnel esista, perché dopo la modifica tocca ogni dispositivo che ha il vecchio indirizzo.

Risolvete presto anche la questione dell’MTU. Un tunnel riduce il carico utile, e una soluzione che dipende dalla frammentazione si comporta diversamente da una che fissa l’MSS sui gateway.

L’inoltro e la politica stanno fuori dal tunnel

Il gateway deve essere disposto a inoltrare pacchetti tra l’interfaccia del tunnel e l’interfaccia LAN, ed entrambe le direzioni hanno bisogno di una politica che consenta il servizio. Su Linux sono due impostazioni separate, più le regole del firewall che decidono se il flusso inoltrato è consentito del tutto.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

L’host ricevente aggiunge un terzo livello: il suo firewall deve comunque accettare un client dalla sottorete remota. Un file server che consente solo la propria /24 locale rifiuterà il traffico inoltrato da 10.20.0.7, per quanto sano sembri il tunnel, e quel rifiuto si legge facilmente come guasto di routing.

Provate da un host, non dal gateway

Un ping originato dal gateway stesso può seguire un indirizzo di origine e una politica diversi da quelli del traffico utente inoltrato. Questo lo rende un test debole e, a volte, fuorviante: riesce mentre l’applicazione fallisce, o fallisce mentre l’applicazione funziona.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Usate un host reale, un indirizzo di origine reale e il protocollo reale che l’applicazione utilizza. Poi leggete il percorso di ritorno separatamente, perché una direzione di andata funzionante senza rotta di ritorno produce un timeout identico a quello di un servizio bloccato.

Scegliete la soluzione in base alla domanda a cui rispondete: state unendo reti o ammettendo dispositivi? Tutto il resto, incluso quale fornitore configurate, deriva da quella risposta.