Inspecția NVA în Azure: de ce răspunsul trece prin alt firewall

Un flux de la sucursală la Azure poate fi rutat corect în ambele direcții și totuși poate eșua, pentru că cele două direcții trec prin aparate diferite. Cererea părăsește sucursala prin VPN, aterizează pe NVA A și ajunge la sarcina de lucru. Răspunsul părăsește sarcina de lucru, se potrivește cu o rută care indică spre NVA B și moare acolo. Fiecare rută din acea imagine este validă, iar sesiunea TCP este totuși ruptă.

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

Acest gol este întreaga temă aici: convergența rutării și proprietatea asupra stării sesiunii sunt probleme diferite care arată identic într-o diagramă.

Ce programează de fapt Route Server

Azure Route Server stabilește peering cu vorbitorii BGP acceptați, le învață rutele și le programează în rutele efective ale rețelei virtuale. Aceasta este o sarcină a planului de control. Nu citește tabelul de sesiuni al unui firewall de la furnizor și nu știe ce aparat a admis o anumită conexiune. Două salturi următoare cu cost egal sunt, pentru această țesătură, pur și simplu două moduri de a ajunge la același prefix, și va folosi oricare.

Învățarea unei rute dovedește deci accesibilitatea. Nu dovedește nimic despre faptul că aparatul de la celălalt capăt a văzut deja acest flux.

Citiți ambele direcții înainte de a proiecta

Începeți prin a nota direcționarea pe care o aveți de fapt în fiecare direcție, nu cea intenționată. Rutele BGP mai specifice, rutele definite de utilizator și comportamentul gateway-ului concurează toate, iar câștigătorul se decide pe destinație, nu pe sesiune. O rută implicită pe NVA nu înseamnă că fiecare prefix privat trece prin ea.

O verificare utilă este să întrebați, pentru un IP anume al sarcinii de lucru, la ce salt următor se rezolvă fiecare direcție. Dacă răspunsul este două aparate diferite, aveți o problemă de asimetrie, fie că s-a manifestat deja, fie nu.

Unde locuiește starea

Un firewall cu stare admite o conexiune și păstrează o intrare de tabel cu cheie pe cvintuplu. Răspunsul trebuie să ajungă la aparatul care deține intrarea, sau acel aparat trebuie să obțină starea altfel. Nimic din planul de date Azure nu transferă intrarea între aparate. Fie traficul este direcționat înapoi la proprietar, fie aparatele partajează starea printr-un mecanism al furnizorului, fie proiectul nu funcționează.

De aceea două NVA sănătoase nu sunt o verificare de sănătate pentru inspecție. Sănătatea ține de accesibilitate; inspecția ține de instanța care deține sesiunea.

Modele HA acceptate și ce promite fiecare

Microsoft's guidance on intenția de rutare a Virtual WAN descrie un comportament limitat pentru conectivitatea cu rol dublu și NVA de firewall, unde rutarea directă poate ocoli aplicarea simetrică normală a hub-ului. Citiți acele note ca restricții asupra topologiei alese, nu ca interdicție a proiectelor activ-activ. O pereche de furnizor care sincronizează starea, sau direcționează pe flux, poate fi acceptată. O pereche cu cost egal care nu face niciuna nu este.

Apoi definiți ce se întâmplă cu sesiunile existente când un nod cade. Convergența rutelor restabilește accesibilitatea pentru fluxurile noi în câteva secunde, în timp ce vechea stare a firewall-ului pur și simplu dispare. Reconectarea clientului poate fi rezultatul documentat, iar aceasta este o decizie luată înainte de incident, nu în timpul lui.

Ce să testați înainte de a avea încredere

Test with inspection enabled and politica de acces a sarcinii de lucru în vigoare, pentru că oricare dintre ele poate ascunde asimetria. Trimiteți un flux autorizat nou în ambele direcții și confirmați că același aparat a văzut ambele jumătăți. Apoi rulați trafic susținut și declanșați comutarea aprobată, observând dacă sesiunile stabilite supraviețuiesc sau se reconectează.

Corelați fiecare flux cu aparatul care l-a gestionat. O captură de pachete pe o singură NVA nu vă spune aproape nimic dacă răspunsul nu s-a întors niciodată acolo.

În final, scrieți planul ca trei linii separate: proprietatea rutelor, direcționarea traficului și proprietatea stării sesiunii. Proiectele se rup când primele două sunt rezolvate, iar a treia este presupusă.