Inspecció de NVA a Azure: per què la resposta passa per un altre tallafoc

Un flux de la sucursal a Azure pot encaminar-se correctament en totes dues direccions i tot i així fallar, perquè les dues direccions passen per aparells diferents. La petició surt de la sucursal per la VPN, arriba a NVA A i arriba a la càrrega de treball. La resposta surt de la càrrega de treball, coincideix amb una ruta que apunta a NVA B i mor allà. Totes les rutes d’aquesta imatge són vàlides, i la sessió TCP continua trencada.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Aquest buit és tot el tema aquí: la convergència d’encaminament i la propietat de l’estat de sessió són problemes diferents que en un diagrama semblen idèntics.

Què programa realment Route Server

Azure Route Server estableix connexió amb els parlants BGP admesos, n’aprèn les rutes i les programa a les rutes efectives de la xarxa virtual. Aquesta és una feina de pla de control. No llegeix la taula de sessions d’un tallafoc de proveïdor i no té ni idea de quin aparell va admetre una connexió concreta. Dos salts següents d’igual cost són, per a aquest teixit, simplement dues maneres d’arribar al mateix prefix, i utilitzarà qualsevol de les dues.

Aprendre una ruta, doncs, demostra abastabilitat. No demostra res sobre si el dispositiu de l’altre extrem ha vist abans aquest flux.

Llegeix les dues direccions abans de dissenyar

Comença escrivint l’orientació que realment tens en cada direcció, no la que tenies prevista. Les rutes BGP més específiques, les rutes definides per l’usuari i el comportament de la passarel·la competeixen totes, i el guanyador es decideix per destinació, no per sessió. Una ruta per defecte a l’NVA no vol dir que tots els prefixos privats hi passin.

Una comprovació útil és preguntar, per a una IP concreta de càrrega de treball, a quin salt següent resol cada direcció. Si la resposta són dos aparells diferents, tens un problema d’asimetria tant si ja ha aparegut com si no.

On viu l’estat

Un tallafoc amb estat admet una connexió i manté una entrada de taula amb clau de la quíntuple. La resposta ha d’arribar al dispositiu que té aquesta entrada, o aquell dispositiu ha d’obtenir l’estat d’una altra manera. Res al pla de dades d’Azure no reenvia l’entrada entre aparells. O el trànsit es torna a dirigir al propietari, o els aparells comparteixen estat mitjançant un mecanisme del proveïdor, o el disseny no funciona.

Per això dos NVAs sans no són una comprovació de salut per a la inspecció. La salut tracta de l’abastabilitat; la inspecció tracta de quina instància té la sessió.

Models d’HA admesos i què promet cadascun

Microsoft's guidance on la intenció d’encaminament de Virtual WAN descriu un comportament limitat per a la connectivitat de doble rol i els NVAs de tallafoc, on l’encaminament directe pot evitar l’aplicació simètrica normal del concentrador. Llegeix aquestes notes com a restriccions a la topologia que has triat, no com a prohibició dels dissenys actiu-actiu. Una parella de proveïdor que sincronitza estat, o que orienta per flux, pot ser admesa. Una parella d’igual cost que no fa cap de les dues coses no ho és.

Després defineix què passa amb les sessions existents quan falla un node. La convergència de rutes restaura l’abastabilitat per als fluxos nous en segons, mentre que l’estat antic del tallafoc simplement desapareix. Una reconnexió del client pot ser el resultat documentat, i això és una decisió que cal prendre abans de l’incident, no durant.

Què cal provar abans de confiar-hi

Test with inspection enabled and la política d’accés de la càrrega de treball al seu lloc, perquè qualsevol de les dues pot amagar l’asimetria. Envia un flux autoritzat nou en totes dues direccions i confirma que el mateix aparell ha vist les dues meitats. Després executa trànsit sostingut i activa el failover aprovat, observant si les sessions establertes sobreviuen o es reconnecten.

Correlaciona cada flux amb l’aparell que el va gestionar. Una captura de paquets en un NVA no et diu gairebé res si la resposta no hi va tornar mai.

Finalment, escriu el pla en tres línies separades: propietat de les rutes, orientació del trànsit i propietat de l’estat de sessió. Els dissenys es trenquen quan les dues primeres estan resoltes i la tercera se suposa.