Ispezione NVA in Azure: perché la risposta passa da un altro firewall
Route Server distribuisce due percorsi uguali e nient’altro. Quando la risposta sceglie un altro dispositivo, quella sessione non ha stato lì e il flusso muore.
Un flusso dalla filiale ad Azure può essere instradato correttamente in entrambe le direzioni e fallire comunque, perché le due direzioni attraversano dispositivi diversi. La richiesta lascia la filiale tramite la VPN, atterra su NVA A e raggiunge il carico di lavoro. La risposta lascia il carico di lavoro, corrisponde a una rotta che punta a NVA B e muore lì. Ogni rotta in quell’immagine è valida, e la sessione TCP è comunque rotta.
Request: branch -> VPN gateway -> NVA A -> workload
Reply: workload -> NVA B -> VPN gateway -> branch
Quello scarto è tutto l’argomento qui: la convergenza di instradamento e la proprietà dello stato di sessione sono problemi diversi che in un diagramma sembrano identici.
Che cosa programma davvero Route Server
Azure Route Server stabilisce un peering con gli speaker BGP supportati, apprende le loro rotte e le programma nelle rotte effettive della rete virtuale. È un lavoro del piano di controllo. Non legge la tabella delle sessioni di un firewall di fornitore e non ha idea di quale dispositivo abbia ammesso una data connessione. Due next hop di pari costo sono, per questa trama, semplicemente due modi per raggiungere lo stesso prefisso, e userà l’uno o l’altro.
Imparare una rotta dimostra quindi la raggiungibilità. Non dimostra nulla sul fatto che il dispositivo all’altro capo abbia già visto questo flusso.
Leggi entrambe le direzioni prima di progettare
Inizia scrivendo lo steering che hai realmente in ciascuna direzione, non quello che intendevi. Le rotte BGP più specifiche, le rotte definite dall’utente e il comportamento del gateway competono tutti, e il vincitore è deciso per destinazione, non per sessione. Una rotta predefinita sull’NVA non significa che ogni prefisso privato la attraversi.
Un controllo utile è chiedere, per un IP specifico del carico di lavoro, a quale next hop si risolve ciascuna direzione. Se la risposta è due dispositivi diversi, hai un problema di asimmetria, che sia già emerso o no.
Dove vive lo stato
Un firewall stateful ammette una connessione e mantiene una voce di tabella con chiave sulla quintupla. La risposta deve raggiungere il dispositivo che detiene quella voce, oppure quel dispositivo deve ottenere lo stato in un altro modo. Nulla nel piano dati di Azure inoltra la voce tra i dispositivi. O il traffico viene riportato al proprietario, o i dispositivi condividono lo stato tramite un meccanismo del fornitore, o il progetto non funziona.
Per questo due NVA sane non sono un controllo di salute per l’ispezione. La salute riguarda la raggiungibilità; l’ispezione riguarda quale istanza detiene la sessione.
Modelli HA supportati e cosa promette ciascuno
Microsoft's guidance on l’intento di instradamento di Virtual WAN descrivono un comportamento limitato per la connettività a doppio ruolo e le NVA firewall, dove l’instradamento diretto può aggirare l’applicazione simmetrica normale dell’hub. Leggi queste note come vincoli sulla topologia scelta, non come divieto di progetti attivo-attivo. Una coppia di fornitori che sincronizza lo stato, o che indirizza per flusso, può essere supportata. Una coppia di pari costo che non fa nessuna delle due cose no.
Poi definisci cosa succede alle sessioni esistenti quando un nodo si guasta. La convergenza delle rotte ripristina la raggiungibilità per i nuovi flussi in pochi secondi, mentre il vecchio stato del firewall è semplicemente sparito. Una riconnessione del client può essere il risultato documentato, ed è una decisione da prendere prima dell’incidente, non durante.
Cosa testare prima di fidarsi
Test with inspection enabled and la politica di accesso del carico di lavoro in vigore, perché l’una o l’altra può nascondere l’asimmetria. Invia un nuovo flusso autorizzato in entrambe le direzioni e conferma che lo stesso dispositivo abbia visto entrambe le metà. Poi esegui traffico sostenuto e attiva il failover approvato, osservando se le sessioni stabilite sopravvivono o si riconnettono.
Correla ogni flusso con il dispositivo che lo ha gestito. Una cattura di pacchetti su una sola NVA non ti dice quasi nulla se la risposta non è mai tornata lì.
Infine, scrivi il piano su tre righe separate: proprietà delle rotte, indirizzamento del traffico e proprietà dello stato di sessione. I progetti si rompono quando le prime due sono risolte e la terza è data per scontata.