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

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 ovdje je cijela tema: konvergencija rutiranja i vlasništvo nad stanjem sesije različiti su problemi koji na dijagramu izgledaju isto.

Što 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 ravnine. On ne čita tablicu sesija vatrozida dobavljača i nema pojma koji je uređaj dopustio danu vezu. Dva sljedeća skoka jednake cijene za ovo su tkivo 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 projektirate

Počnite tako da zapišete usmjeravanje koje stvarno imate u svakom smjeru, a ne ono koje ste namjeravali. Specifičnije BGP rute, rute koje je definirao korisnik i ponašanje mrežnog prolaza natječu se 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

Vatrozid 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 podatkovnoj ravnini ne prosljeđuje zapis između uređaja. Ili se promet usmjerava natrag vlasniku, ili uređaji dijele stanje kroz mehanizam dobavljača, ili dizajn ne funkcionira.

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 što svaki obećava

Microsoft's guidance on namjeri rutiranja Virtual WAN opisuju ograničeno ponašanje za povezivanje s dvojnom ulogom i vatrozidne NVA, gdje izravno 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 sinkronizira stanje ili usmjerava po toku može biti podržan. Par jednake cijene koji ne čini ni jedno nije.

Zatim definirajte što se događa s postojećim sesijama kad čvor padne. Konvergencija ruta vraća dostupnost za nove tokove u sekundama, dok staro stanje vatrozida jednostavno nestaje. Ponovno povezivanje klijenta može biti dokumentirani ishod, a to je odluka koju treba donijeti prije incidenta, a ne tijekom njega.

Što 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 polovice. Zatim pustite kontinuirani promet i pokrenite odobreni failover, promatrajući da li uspostavljene sesije preživljavaju ili se ponovno 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 retka: vlasništvo nad rutama, usmjeravanje prometa i vlasništvo nad stanjem sesije. Dizajni se lome kada su prva dva riješena, a treće se pretpostavlja.