Due tunnel IPsec attivi hanno ancora bisogno di un piano per il percorso di ritorno

Apri un terminale su una stazione di lavoro in un sito e connettiti a un server nell’altro. Quella singola conversazione TCP ora deve attraversare quattro gateway invece di due, e la parte interessante non è se funziona in una giornata favorevole. La parte interessante è quale coppia di gateway abbia scelto la direzione di andata, quale coppia scelga la risposta e chi detiene lo stato del flusso mentre accade. Niente nella tabella di routing decide questo per te.

Disegna quattro gateway prima di disegnare una rotta

Un progetto doppiamente attivo con due firewall VPN indipendenti per sito, una coppia per provider, ti dà due percorsi utilizzabili e tre modi per romperli. Annota gli indirizzi prima di configurare qualsiasi cosa: il client come si vede prima e dopo ogni gateway, il server allo stesso modo, il salto successivo in andata e il salto successivo al ritorno.

Quella tabella è il progetto. Tutto ciò che segue è una questione se i dispositivi sono d’accordo con la tabella.

Come viene scelto il percorso di andata

Uno strato di routing multipath a costo uguale distribuisce i flussi sui salti successivi eseguendo l’hash dei campi di intestazione, cosa che RFC 2992 descrive in dettaglio. Quella selezione può essere del tutto senza stato: non richiede alcuna voce di tracciamento delle connessioni, solo un hash stabile su campi immutati. Mantieni costanti l’insieme dei percorsi e gli input dell’hash e ogni pacchetto del flusso sceglierà lo stesso salto successivo.

La selezione per flusso evita il riordino che il bilanciamento pacchetto per pacchetto causerebbe su collegamenti con ritardi diversi. Non promette che un costo di routing uguale significhi una latenza misurata uguale, perché non è così. E quando la composizione dei percorsi cambia, i flussi vengono rimappati, quindi la sopravvivenza della connessione durante un guasto è un requisito separato dalla selezione del percorso.

Ciò che serve davvero al percorso di ritorno

Qui il percorso smette di essere simmetrico. Un hash di andata stabile non ti dice nulla su ciò che farà il sito remoto con la risposta. Se un firewall indipendente deve vedere entrambe le direzioni della connessione per mantenere uno stato utile, una rotta di ritorno che lo aggira lascia traffico che non corrisponde a nulla. Due apparati con insiemi di regole simili non sono stato condiviso.

Conferma il comportamento bidirezionale implementato, oppure scrivi una policy esplicita che mantenga coerenti i confini richiesti. Un’ipotesi qui viene scoperta durante un disservizio, da persone che non se la stanno godendo.

Dove la traduzione decide per te

NAT è l’altra leva, ed è facoltativa anziché obbligatoria. Identità tradotte specifiche del percorso possono indirizzare le risposte verso il gateway che detiene lo stato, il che è un progetto legittimo. Aggiungono però mappature, rotte di ritorno e un proprietario di quello stato, quindi accetta il peso solo per un requisito che puoi dire ad alta voce.

Se il requisito è semplicemente che entrambi i percorsi portino traffico e che uno dei due sopravviva alla perdita di un provider, il multipath per flusso con routing di ritorno coerente è di solito il progetto più piccolo.

Percorri l’accettazione in ordine

Prova in questa sequenza e registra gli indirizzi a ogni passo: una nuova connessione sul percorso A e il suo percorso di risposta, lo stesso sul percorso B, poi la perdita di un provider, poi il ripristino. Per ogni risultato annota quali flussi stabiliti si sono spostati, quali hanno dovuto riconnettersi e dove sono andati i nuovi flussi dopo. Scrivi prima il valore atteso, poi confrontalo con la cattura. Due tunnel stabiliti non dimostrano nulla di tutto ciò.

Il progetto è finito quando la tabella che hai scritto corrisponde a ciò che mostra la cattura, non quando entrambi i tunnel sono attivi.