Azure NVA inspekcija: kodėl atsakymas eina per kitą ugniasienę

Srautas iš filialo į Azure gali būti teisingai maršrutizuotas abiem kryptimis ir vis tiek nepavykti, nes abi kryptys eina per skirtingus įrenginius. Užklausa palieka filialą per VPN, nusileidžia ant NVA A ir pasiekia darbo krūvį. Atsakymas palieka darbo krūvį, atitinka maršrutą, rodantį į NVA B, ir ten žūva. Kiekvienas maršrutas tame paveiksle galioja, o TCP sesija vis tiek sulaužyta.

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

Ši spraga čia yra visa tema: maršrutizavimo konvergencija ir sesijos būsenos nuosavybė yra skirtingos problemos, kurios diagramoje atrodo identiškai.

Ką Route Server iš tikrųjų programuoją

Azure Route Server užmezga peering su palaikomais BGP kalbėtojais, išmoksta jų maršrutus ir suprogramuoja juos virtualaus tinklo efektyviuose maršrutuose. Tai valdymo plokštumos darbas. Jis neskaito pardavėjo ugniasienės sesijų lentelės ir nežino, kuris įrenginys leido tam tikrą ryšį. Du vienodos kainos kiti šuoliai šiam audiniui yra tiesiog du būdai pasiekti tą patį prefiksą, ir jis naudos bet kurį.

Taigi maršruto išmokimas įrodo pasiekiamumą. Jis nieko neįrodo apie tai, ar įrenginys kitame gale jau matė šį srautą.

Perskaitykite abi kryptis prieš projektuodami

Pradėkite užsirašydami valdymą, kurį iš tikrųjų turite kiekviena kryptimi, o ne tą, kurį ketinote. Konkretesni BGP maršrutai, vartotojo apibrėžti maršrutai ir šliuzo elgsena visi konkuruoja, o nugalėtojas nustatomas pagal paskirties vietą, ne pagal sesiją. Numatytasis maršrutas NVA nereiškia, kad kiekvienas privatus prefiksas eina per jį.

Naudingas patikrinimas yra paklausti, vieno konkretaus darbo krūvio IP atveju, į kurį kitą šuolį išsprendžiama kiekviena kryptis. Jei atsakymas yra du skirtingi įrenginiai, turite asimetrijos problemą, nesvarbu, ar ji jau pasireiškė.

Kur gyvena būsena

Būseną sekanti ugniasienė priima ryšį ir laiko lentelės įrašą, kurio raktas yra penketukas. Atsakymas turi pasiekti įrenginį, turintį tą įrašą, arba tas įrenginys turi gauti būseną kitu būdu. Niekas Azure duomenų plokštumoje neperduoda įrašo tarp įrenginių. Arba srautas nukreipiamas atgal savininkui, arba įrenginiai dalijasi būsena per pardavėjo mechanizmą, arba projektas neveikia.

Štai kodėl du sveiki NVA nėra inspekcijos sveikatos patikrinimas. Sveikata yra apie pasiekiamumą; inspekcija yra apie tai, kuri instancija turi sesiją.

Palaikomi HA modeliai ir ką kiekvienas žada

Microsoft's guidance on Virtual WAN maršrutizavimo ketinimą aprašo ribotą elgseną dvigubo vaidmens junglumui ir ugniasienės NVA, kai tiesioginis maršrutizavimas gali apeiti įprastą simetrinį hub'o vykdymą. Skaitykite tas pastabas kaip pasirinktos topologijos apribojimus, o ne kaip aktyvių-aktyvių projektų draudimą. Pardavėjo pora, kuri sinchronizuoja būseną arba nukreipia pagal srautą, gali būti palaikoma. Vienodos kainos pora, kuri nedaro nė vieno, nėra.

Tada apibrėžkite, kas nutinka esamoms sesijoms, kai mazgas sugenda. Maršrutų konvergencija atkuria pasiekiamumą naujiems srautams per sekundes, o sena ugniasienės būsena tiesiog dingsta. Kliento pakartotinis prisijungimas gali būti dokumentuotas rezultatas, ir tai sprendimas, priimamas prieš incidentą, o ne jo metu.

Ką išbandyti prieš juo pasitikint

Test with inspection enabled and darbo krūvio prieigos politika vietoje, nes bet kuri iš jų gali paslėpti asimetriją. Nusiųskite naują leistiną srautą abiem kryptimis ir patvirtinkite, kad tas pats įrenginys matė abi puses. Tada paleiskite nuolatinį srautą ir suaktyvinkite patvirtintą perjungimą, stebėdami, ar nusistovėjusios sesijos išlieka, ar prisijungia iš naujo.

Koreliuokite kiekvieną srautą su jį apdorojusiu įrenginiu. Paketų fiksavimas viename NVA beveik nieko nepasako, jei atsakymas niekada negrįžo ten.

Galiausiai parašykite planą trimis atskiromis eilutėmis: maršrutų nuosavybė, srauto nukreipimas ir sesijos būsenos nuosavybė. Projektai lūžta, kai pirmieji du išspręsti, o trečiasis laikomas savaime suprantamu.