Aggiungere una seconda sottorete a una VPN site-to-site: due percorsi
I tunnel basati su policy richiedono selettori corrispondenti su entrambi i lati; quelli basati su rotte richiedono una rotta. Scegliete il percorso giusto e correggete prima la rotta di ritorno.
Aggiungere una seconda sottorete a un tunnel site-to-site funzionante richiede cinque minuti in un progetto e quasi tutto il pomeriggio nell’altro. Quando il tunnel installa rotte per i prefissi che nominate, aggiungete una rotta e il traffico la segue. Quando negozia una coppia di selettori fissa, il nuovo prefisso resta senza protezione finché entrambi i lati non concordano una coppia corrispondente. Tre cose decidono il caso: cosa descrive davvero la configurazione di ciascun lato, se il traffico negoziato si restringe alla coppia corrispondente più piccola e a chi appartiene la rotta di ritorno per il nuovo intervallo.
Leggete il kernel, non l’etichetta di stato
Un tunnel che segnala connessione ha installato almeno un’associazione figlia, non necessariamente quella che pensate. Su Linux il kernel mostra cosa viene applicato: ip xfrm policy elenca le coppie di selettori e swanctl --list-sas (o il vecchio ipsec statusall) mostra cosa hanno negoziato i lati, inclusi i selettori di traffico in ciascuna direzione. Se il nuovo prefisso non compare in nessuna delle due, è senza protezione, qualunque cosa dica il file di configurazione.
Confrontatelo con la tabella delle rotte. In un impianto basato su rotte il dispositivo del tunnel è il salto successivo per i prefissi protetti. Un impianto basato su policy spesso non ha una rotta specifica per la sottorete remota, solo quella predefinita, perché è la policy a scegliere il traffico, non la tabella.
Tunnel basati su policy: entrambi i lati devono elencare il nuovo prefisso
In termini strongSwan il selettore vive in local_ts e remote_ts nella configurazione figlia, successori di leftsubnet e rightsubnet. Il nuovo prefisso deve comparire su entrambi i lati a specchio: ciò che il sito A chiama locale, il sito B lo chiama remoto. Una discordanza raramente produce un errore pulito. I lati si restringono all’intersezione, il vecchio prefisso continua a funzionare e solo il nuovo fallisce in silenzio.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policySu pfSense o OPNsense significa una seconda voce Phase 2 che accoppia la nuova sottorete locale alla nuova remota, poi un’applicazione. Mantenete la voce vecchia; sostituirla sposta la sottorete originale invece di aggiungerla. Se una Phase 2 esistente copre già una supernet come 0.0.0.0/0 o un intervallo riassunto, non aggiungete una voce più stretta accanto: selettori sovrapposti installano policy concorrenti e l’ordine di valutazione decide quale vince.
IKEv1 rende ogni coppia di sottoreti una Phase 2 propria, e un lato che accetta una coppia per scambio scarta le altre. IKEv2 può portare più coppie di selettori in un figlio, ma solo se entrambe le implementazioni le accettano. L’elenco da swanctl --list-sas è la verità; quello che avete digitato è una richiesta.
Tunnel basati su rotte: la rotta è la policy
Un’interfaccia XFRM o un dispositivo VTI porta il traffico secondo la tabella delle rotte. Puntate il nuovo prefisso al dispositivo su entrambi i siti e si applica lo stato legato alla trasformazione dell’interfaccia. Non c’è alcuna coppia di selettori da sincronizzare, perciò questo progetto scala meglio quando le sottoreti si moltiplicano. La guida all’inoltro di strongSwan approfondisce il lato kernel.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard spinge l’idea oltre. AllowedIPs è insieme la lista bianca crittografica e, tramite wg-quick, la voce nella tabella delle rotte. Aggiungete il prefisso solo su un lato e otterrete stretta di mano, pacchetti in uscita e silenzio, perché il lato remoto scarta i pacchetti la cui origine non è nella sua lista. La forma wg set sostituisce l’intera lista, quindi ripetete i prefissi che già funzionavano o li taglierete:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Quel secondo comando non è facoltativo quando avete usato wg set invece di wg-quick. Il kernel accetta subito la nuova lista, ma nulla vi aggiunge una rotta, quindi il traffico generato localmente esce ancora dal gateway predefinito. È il motivo più comune per cui una nuova sottorete WireGuard funziona dall’host del tunnel e non da un portatile.
La rotta di ritorno fallisce più spesso del tunnel
Gli host della nuova sottorete remota devono inviare le risposte attraverso il gateway VPN. Quando quel gateway non è il loro router predefinito, la risposta va al router della LAN, che la scarta o la inoltra a internet con un indirizzo sorgente privato. Provate da un host sul lato remoto, non dal gateway: ip route get 10.30.20.15 su Linux o Find-NetRoute -RemoteIPAddress 10.30.20.15 in PowerShell mostra il salto successivo che l’host userà davvero. Se la risposta non è l’endpoint del tunnel, aggiungete lì una rotta statica per il nuovo prefisso.
Il NAT sorgente sul sito privo della rotta di ritorno è un’alternativa legittima ed è come molti impianti hub-and-spoke evitano di toccare ogni server. Applicatelo anche al nuovo prefisso sul gateway del lato destinazione:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEIl costo è reale. I log remoti smettono di mostrare indirizzi sorgente individuali e le regole firewall basate sulla sottorete originale collassano in un’unica regola per il gateway. Sceglietelo di proposito, non perché mancava una rotta.
I firewall sono l’altra metà della rotta di ritorno. I dispositivi a zone non estendono automaticamente la zona di un’interfaccia tunnel esistente a una nuova sottorete, e una regola scritta per il vecchio prefisso non corrisponderà. Aggiungete la nuova sottorete alla zona o alla coppia di regole in entrambe le direzioni prima di dare la colpa a IPsec.
Decidete con tre domande, poi verificate con traffico
Versione rapida: la configurazione del lato nomina prefissi (basata su policy) o il traffico viene instradato in un’interfaccia (basata su rotte)? Entrambe le estremità elencano il nuovo prefisso? Esiste un percorso di ritorno dalla nuova sottorete all’intervallo sorgente originale?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
La verifica è il punto in cui la maggior parte delle modifiche viene chiusa troppo presto. Un ping dal gateway dimostra poco, perché il gateway invia da sé e spesso corrisponde a una policy diversa da quella di un host. Fate ping da un host sulla nuova sottorete, poi eseguite l’applicazione che ha motivato la modifica e guardate i contatori, non un’icona di stato.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showSu un tunnel basato su policy i contatori di ip xfrm state devono salire in entrambe le direzioni; contatori piatti significano che il pacchetto è instradato ma non selezionato. Su WireGuard wg show riporta il trasferimento per lato, e una stretta di mano con zero byte ricevuti indica la lista del lato remoto o la sua rotta di ritorno.
Concludete registrando il prefisso, il selettore o la rotta del lato, la decisione sulla rotta di ritorno e la voce firewall insieme al resto dell’inventario del tunnel. Poi riavviate un gateway e provate di nuovo: una rotta aggiunta a mano sparisce e la persona successiva non dovrebbe doverlo riscoprire.