Cambiare fornitore senza rinumerare gli indirizzi VPN del sito

Una filiale cambia fornitore internet e il file server conserva il suo indirizzo. Questo esito è normale in una VPN di sito instradata e sorprendente per chi presume che l'indirizzo dell'estremità del tunnel sia l'indirizzo dell'applicazione. I due vivono in livelli diversi del progetto e solo uno si è spostato. Trattarli come uno solo è il modo in cui una migrazione del fornitore diventa un progetto di rinumerazione.

Due piani di indirizzamento che si muovono in modo indipendente

Il piano interno descrive gli indirizzi privati che le applicazioni usano: il server della filiale su 10.55.8.20, il prefisso della sede centrale che instrada verso di esso e la rotta di ritorno. Il piano esterno descrive come due gateway si raggiungono: indirizzi dei peer, porte di ascolto e il percorso attraverso internet.

Un cambio di fornitore tocca il piano esterno. Di per sé non richiede che il piano interno cambi.

Tenere separati i due inventari è la ragione pratica per eseguire un overlay anche quando l'applicazione cifra già il proprio traffico. L'overlay offre una topologia interna stabile che sopravvive ai cambiamenti esterni. L'applicazione mantiene il suo indirizzo, le sue regole del firewall e i suoi record DNS. Cambiano solo le voci di trasporto, ed è una revisione molto più piccola.

Il tunnel esterno trasporta la conversazione interna

In un tunnel da gateway a gateway, l'intestazione IP esterna indirizza i due gateway. L'intestazione interna nomina ancora gli endpoint reali dell'applicazione. La descrizione da gateway a gateway dell'RFC 7296 la tratta come instradamento ordinario che consegna il traffico attraverso gli endpoint del tunnel.

Per questo il server della filiale può conservare 10.55.8.20 mentre l'indirizzo pubblico del gateway cambia. Il pacchetto interno non contiene affatto l'indirizzo del fornitore.

La separazione è una proprietà del progetto, non una garanzia automatica. Se il collegamento sostitutivo non riesce a stabilire il tunnel supportato, o le rotte interne non vengono reinstallate, l'applicazione perde il suo percorso anche se il suo indirizzo non è cambiato.

Lo spostamento del fornitore ha ancora una lista di controllo

La lista esterna ha cinque voci: l'indirizzo del peer o il nome mantenuto, il listener e qualsiasi filtraggio a monte, la traduzione sul percorso, l'identità attesa del peer e le impostazioni consentite dell'altro gateway. Ognuna può fallire da sola. Mantieni un percorso di ripristino separato mentre cambi il collegamento che porta l'amministrazione. Tagliare l'accesso remoto durante un cambio di collegamento è un'interruzione che ti sei procurato da solo.

Dopo, controlla il prefisso della filiale, la rotta in entrambe le direzioni, la politica di protezione e un flusso applicativo reale. Un tunnel appena autenticato non sistema una rotta che punta alla vecchia sottorete privata.

La sovrapposizione di indirizzi con un altro sito connesso è un problema di pianificazione a parte. Il cambio di fornitore non lo crea, ma una migrazione è di solito il momento in cui emerge.

Ciò che non sopravvive: sorgente pubblica e sessioni

Un indirizzo privato di server stabile non è una sorgente pubblica stabile. Se la navigazione esce direttamente dal nuovo fornitore, i siti vedono il nuovo indirizzo rivolto al fornitore.

Mantenere quell'indirizzo stabile richiede un progetto di uscita deliberato, con la sua disponibilità e la sua politica. Non arriva gratis con il tunnel.

Neanche le sessioni stabilite sopravvivono a un cambio di percorso. Il tunnel può ristabilirsi in pochi secondi e comunque rompere connessioni di lunga durata ancorate al vecchio percorso. Pianifica il cambio per una finestra in cui le riconnessioni sono accettabili. Non affermare che una migrazione sarà invisibile se non sono stati provati i client specifici e i loro timeout.

Verifica lo spostamento con quattro controlli

Dopo il cambio, verifica quattro cose in ordine: il tunnel è stabilito con il peer previsto, la rotta interna verso il prefisso della filiale esiste, la politica consente il flusso applicativo e l'applicazione risponde. Ognuna ha il proprio comando.

Su un gateway Linux, questi tre coprono la metà di quell'elenco:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Tieni gli indirizzi di trasporto in un inventario e gli indirizzi applicativi in un altro. Aggiorna solo le voci che si sono davvero spostate. Rinumerare dipendenze interne perché l'indirizzo esterno del tunnel è cambiato è lavoro evitabile.