Migrare una sottorete su un nuovo tunnel VPN senza interruzioni

Alzate il nuovo tunnel, spostate una sottorete, e quella sottorete ora fallisce a intermittenza mentre tutto il resto funziona perfettamente. Le VPN migrate a metà falliscono esattamente così, perché il tunnel non è mai stata la parte difficile. Il percorso comprende anche quale rotta vince, quali selettori corrispondono, cosa consentono le regole di accesso, come tornano le risposte e qualsiasi traduzione applicasse il vecchio progetto. Spostate solo il tunnel e non avrete spostato nulla di tutto questo.

Il tunnel è la metà facile del percorso

I guasti intermittenti dopo una migrazione parziale di solito significano che due percorsi sono entrambi plausibili. Alcuni flussi scelgono il tunnel nuovo, altri restano sul vecchio, e un dispositivo con stato vede allora arrivare una risposta su un percorso che la richiesta non ha mai usato. Due percorsi non sono automaticamente più sicuri di uno; sono due cose che possono discordare. Guardate i rapporti di oscillazione e non i contatori del tunnel, perché i contatori sembreranno sani per tutta la durata.

La prima domanda utile non è quale tunnel sia migliore. È quali flussi scelgono quale percorso oggi, e se la richiesta e la risposta ottengono la stessa risposta.

Costruite la destinazione prima di preferirla

Confermate che i peer sono compatibili e che il nuovo tunnel porta l'ambito di indirizzi che intendete. Aggiungete l'inoltro e le autorizzazioni di servizio che servono mentre è ancora il percorso non preferito, così il taglio stesso cambia solo la selezione e nient'altro.

Chiedete al sito remoto come restituirà il traffico. Se le risposte escono ancora dal tunnel vecchio, una nuova rotta locale produce asimmetria o fallisce su un filtro che ricorda lo stato. Anche la traduzione appartiene al progetto per lo stesso motivo: un indirizzo di origine cambiato cambia anche il percorso di ritorno.

Tagliate in modo stretto e conoscete la via del ritorno

Nominate la sottorete esatta e il meccanismo supportato dalla piattaforma che preferisce la sua nuova rotta o il suo selettore. Le definizioni basate su policy non si comportano sempre come metriche di rotta, quindi leggete le regole delle policy sovrapposte della vostra implementazione prima di supporre che vinca la corrispondenza più specifica.

Spostate una sottorete, non un sito. Tenete l'accesso di gestione su un percorso che non toccate, e scrivete il rollback prima di applicare qualcosa: quale rotta o policy torna indietro, chi lo fa e come restano connessi mentre lo fanno.

Asimmetria e stato obsoleto

I firewall e i dispositivi NAT ricordano l'interfaccia usata da un flusso. Quando richiesta e risposta prendono tunnel diversi, il dispositivo può scartare la risposta anche se ciascun percorso funziona da solo. Provate con un flusso che aprite dopo la modifica, perché una sessione stabilita può continuare a usare il vecchio percorso per ore.

Se l'indirizzo di origine osservato si è spostato, trovate ogni policy che nomina quello vecchio. Una migrazione che cambia l'origine in silenzio rompe regole che nessuno aveva classificato come parte del progetto VPN.

Dimostrate entrambe le risposte, poi ritirate la vecchia policy

Da un host normale sulla sottorete migrata, raggiungete il servizio previsto e controllate l'origine osservata e l'interfaccia di risposta. Poi provate una rete che deve restare sul tunnel vecchio, perché una migrazione è finita solo quando entrambe le risposte sono corrette. Il secondo test è quello che la gente salta, ed è quello che intercetta un selettore più ampio del previsto.

Ritirate la policy obsoleta solo quando nessuna sottorete rimanente dipende da essa, e registrate la rotta finale con il suo proprietario nell'inventario dei selettori. Finire non è che il nuovo tunnel segnali di essere su; è che ogni rete segua il percorso previsto.