Azure NVA inspekcija: zašto odgovor prolazi kroz drugi firewall

Tok od podružnice do Azurea može biti ispravno rutiran u oba smjera i ipak ne uspjeti, jer dva smjera idu kroz različite uređaje. Zahtjev napušta podružnicu preko VPN-a, dolazi na NVA A i stiže do radnog opterećenja. Odgovor napušta radno opterećenje, poklapa se s rutom koja pokazuje na NVA B i umire tamo. Svaka ruta na toj slici je valjana, a TCP sesija je i dalje prekinuta.

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

Ta praznina je ovdje cijela tema: konvergencija rutiranja i vlasništvo nad stanjem sesije različiti su problemi koji na dijagramu izgledaju isto.

Šta Route Server zapravo programira

Azure Route Server uspostavlja peer odnos s podržanim BGP govornicima, uči njihove rute i programira ih u efektivne rute virtualne mreže. To je posao kontrolne ravni. On ne čita tablicu sesija firewall-a dobavljača i nema pojma koji je uređaj dopustio datu vezu. Dva sljedeća skoka jednake cijene za ovu su tkaninu samo dva načina da se dosegne isti prefiks i koristit će bilo koji.

Učenje rute stoga dokazuje dostupnost. Ne dokazuje ništa o tome je li uređaj na drugom kraju već vidio ovaj tok.

Pročitajte oba smjera prije nego što projektujete

Počnite tako što ćete zapisati usmjeravanje koje stvarno imate u svakom smjeru, a ne ono koje ste namjeravali. Specifičnije BGP rute, rute koje je definisao korisnik i ponašanje mrežnog prolaza se natječu i pobjednik se odlučuje po odredištu, a ne po sesiji. Zadana ruta na NVA ne znači da svaki privatni prefiks prolazi kroz nju.

Korisna provjera je pitati, za jednu konkretnu IP adresu radnog opterećenja, na koji se sljedeći skok razrješava svaki smjer. Ako su odgovor dva različita uređaja, imate problem asimetrije bez obzira na to je li se već pojavio.

Gdje stanje živi

Firewall sa praćenjem stanja prima vezu i drži zapis u tablici s ključem petorke. Odgovor mora stići do uređaja koji drži taj zapis, ili taj uređaj mora dobiti stanje na drugi način. Ništa u Azure data ravni ne prosljeđuje zapis između uređaja. Ili se saobraćaj usmjerava natrag vlasniku, ili uređaji dijele stanje kroz mehanizam dobavljača, ili dizajn ne funkcioniše.

Zato dva zdrava NVA nisu zdravstvena provjera za inspekciju. Zdravlje se odnosi na dostupnost; inspekcija se odnosi na to koja instanca drži sesiju.

Podržani HA modeli i šta svaki obećava

Microsoft's guidance on namjeri rutiranja Virtual WAN opisuju ograničeno ponašanje za povezivanje s dvojnom ulogom i firewall NVA, gdje direktno rutiranje može zaobići normalno simetrično provođenje čvorišta. Čitajte te bilješke kao ograničenja na topologiju koju ste odabrali, ne kao zabranu aktivno-aktivnih dizajna. Par dobavljača koji sinhronizira stanje ili usmjerava po toku može biti podržan. Par jednake cijene koji ne čini ni jedno nije.

Zatim definirajte šta se dešava s postojećim sesijama kada čvor padne. Konvergencija ruta vraća dostupnost za nove tokove u sekundama, dok staro stanje firewall-a jednostavno nestaje. Ponovno povezivanje klijenta može biti dokumentovani ishod, a to je odluka koju treba donijeti prije incidenta, a ne tokom njega.

Šta testirati prije nego što mu vjerujete

Test with inspection enabled and politikom pristupa radnog opterećenja na mjestu, jer bilo koje od toga može sakriti asimetriju. Pošaljite novi ovlašteni tok u oba smjera i potvrdite da je isti uređaj vidio obje polovine. Zatim pustite kontinuirani saobraćaj i pokrenite odobreni failover, posmatrajući da li uspostavljene sesije preživljavaju ili se ponovo povezuju.

Povežite svaki tok s uređajem koji ga je obradio. Snimanje paketa na jednom NVA ne govori gotovo ništa ako se odgovor nikada nije vratio na njega.

Na kraju, napišite plan kao tri odvojena reda: vlasništvo nad rutama, usmjeravanje saobraćaja i vlasništvo nad stanjem sesije. Dizajni se lome kada su prva dva riješena, a treće se pretpostavlja.