VPN di filiale su 4G: mantieni stabile l'identità quando l'IP si sposta

Parti dalla filiale stessa, nella pagina di stato WAN del router 4G. Se l'indirizzo che vedi si trova nell'intervallo privato dell'operatore anziché in uno pubblico, nessun inoltro di porta su quel dispositivo permetterà mai all'hub di chiamare verso l'interno, e il tunnel va costruito verso l'esterno dalla filiale. Quella singola osservazione decide il progetto. Il resto del lavoro consiste nell'assicurarsi che l'hub riconosca la filiale per qualcosa di meglio di un indirizzo che cambia ogni poche ore.

Dove deve iniziare il tunnel

Controlla l'indirizzo rispetto allo spazio di indirizzamento condiviso che gli operatori usano per il proprio NAT, 100.64.0.0/10, e rispetto ai normali intervalli privati. Vederne uno su un collegamento mobile di solito significa che un NAT di livello operatore sta tra la filiale e internet, e che le connessioni in ingresso non sono disponibili a nessun prezzo che la filiale possa pagare. Quando l'indirizzo WAN è pubblico ma cambia, hai un altro problema, più semplice.

Il DNS dinamico aiuta solo nel secondo caso. Dà a un indirizzo pubblico variabile un nome stabile da chiamare, e non può creare una mappatura che l'operatore non ha mai fornito. Vale comunque la pena configurarlo per il caso pubblico, perché elimina l'unico passaggio manuale di una rinumerazione. Ciò che non deve diventare è la risposta per una filiale che l'operatore non ha mai reso raggiungibile.

Separa l'indirizzo che chiami dall'identità che abbini

L'hub ha bisogno di qualcosa di stabile su cui essere trovato, un indirizzo fisso approvato o un nome host mantenuto. La filiale ha bisogno di un modo stabile per essere riconosciuta, e in IKEv2 questo è il payload di identità che presenta durante l'autenticazione, indipendentemente dall'indirizzo di origine che i suoi pacchetti trasportano. Una stringa come @branch-a.vpn.example funziona come quell'identità anche mentre l'indirizzo mobile cambia ogni ora.

Quella stringa viene confrontata con la policy, non risolta tramite DNS, quindi non aspettarti una ricerca all'instaurazione del tunnel. La configurazione dell'hub deve nominare esplicitamente l'identità attesa, e con l'autenticazione a certificato l'identità deve anche corrispondere a ciò che il certificato afferma realmente.

Accettare qualsiasi identità perché l'indirizzo di origine sembra plausibile è la modalità di guasto da evitare. Su un responder significa accettare qualsiasi peer, con un carattere jolly di identità e un segreto condiviso, il che autentica una stringa anziché un dispositivo.

Scrivi il lato hub come peer con nome

In termini strongSwan il lato responder è una connessione con right=%any, che accetta un peer da qualsiasi indirizzo di origine, più [email protected], che fissa ciò che quel peer deve dichiarare di essere. Aggiungi rightsubnet=10.20.0.0/16 per le LAN della filiale, auto=add così la connessione viene caricata senza essere chiamata, dpd_delay=30s per la vitalità e mobike=yes così un cambio di indirizzo viene assorbito invece di essere trattato come un nuovo peer.

Altri fornitori esprimono gli stessi oggetti con nomi diversi, di solito un tipo di peer dinamico o di filiale con un campo identità e un campo subnet protetta. Compila entrambi; una casella dinamica generica non è un piano di compatibilità.

Mantieni la filiale come iniziatore

Sulla filiale vale l'immagine speculare: left=%defaultroute perché l'indirizzo mobile locale sia usato così com'è ora, [email protected] per presentare l'identità, right=hub.example.com per il nome stabile dell'hub, e auto=start perché il tunnel salga senza una persona. Quando il collegamento mobile si riconnette, la filiale riavvia e l'hub abbina la stessa identità allo stesso oggetto di policy.

Consenti IKE su UDP 500, il passaggio NAT su UDP 4500 e l'ESP incapsulato che segue, su entrambi i lati. Poi lasciali consentiti: una regola che si apre solo durante l'orario di lavoro sembrerà un tunnel intermittente.

Prova il cambio di indirizzo, non solo la prima stretta di mano

Alza il tunnel, confermalo, poi forza la filiale su un nuovo indirizzo attivando e disattivando i dati mobili o la modalità aereo per un minuto. Osserva l'elenco delle associazioni di sicurezza sull'hub e verifica che l'indirizzo del peer sia cambiato mentre l'identità no. Un tunnel che funziona solo fino alla prima riassegnazione dell'operatore non è stato affatto testato.

Poi controlla le subnet protette separatamente. Una SA stabilita dice che i peer si sono autenticati; non dice che l'hub abbia una rotta verso la LAN della filiale né che la filiale accetti traffico dal lato hub. Leggi la tabella di routing e la policy del firewall separatamente, poi invia un ping da un host invece che dal gateway, perché il gateway è il dispositivo meno rappresentativo di qualsiasi rete.

Un'identità stabile trasforma la filiale in un oggetto di policy che l'hub può nominare. Non rende raggiungibile un indirizzo NAT dell'operatore e non concede da sola al resto dell'organizzazione l'accesso alla filiale.