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

Tok od ogranka do Azurea može biti ispravno rutiran u oba smera i ipak ne uspeti, jer dva smera idu kroz različite uređaje. Zahtev napušta ogranak preko VPN-a, dolazi na NVA A i stiže do radnog opterećenja. Odgovor napušta radno opterećenje, poklapa se sa 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 ovde cela tema: konvergencija rutiranja i vlasništvo nad stanjem sesije su različiti problemi koji na dijagramu izgledaju isto.

Šta Route Server zapravo programira

Azure Route Server uspostavlja peer odnos sa podržanim BGP govornicima, uči njihove rute i programira ih u efektivne rute virtuelne mreže. To je posao kontrolne ravni. On ne čita tabelu sesija firewall-a dobavljača i nema pojma koji je uređaj dopustio datu vezu. Dva sledeća skoka jednake cene za ovo su tkivo samo dva načina da se dosegne isti prefiks i koristiće bilo koji.

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

Pročitajte oba smera pre nego što projektujete

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

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

Gde stanje živi

Firewall sa praćenjem stanja prima vezu i drži zapis u tabeli sa 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 prosleđuje zapis između uređaja. Ili se saobraćaj usmerava natrag vlasniku, ili uređaji dele stanje kroz mehanizam dobavljača, ili dizajn ne funkcioniše.

Zato dva zdrava NVA nisu zdravstvena provera 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 nameri rutiranja Virtual WAN opisuju ograničeno ponašanje za povezivanje sa dvojnom ulogom i firewall NVA, gde direktno rutiranje može zaobići normalno simetrično sprovođenje čvorišta. Čitajte te beleške kao ograničenja na topologiju koju ste odabrali, ne kao zabranu aktivno-aktivnih dizajna. Par dobavljača koji sinhronizuje stanje ili usmerava po toku može biti podržan. Par jednake cene koji ne čini ni jedno nije.

Zatim definišite šta se dešava sa 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 doneti pre incidenta, a ne tokom njega.

Šta testirati pre nego što mu verujete

Test with inspection enabled and politikom pristupa radnog opterećenja na mestu, jer bilo koje od toga može sakriti asimetriju. Pošaljite novi ovlašteni tok u oba smera i potvrdite da je isti uređaj video obe 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 sa 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, usmeravanje saobraćaja i vlasništvo nad stanjem sesije. Dizajni se lome kada su prva dva rešena, a treće se pretpostavlja.