Azure'i NVA kontroll: miks vastus läheb läbi teise tulemüüri

Voog harust Azure'i võib olla mõlemas suunas õigesti marsruuditud ja siiski ebaõnnestuda, sest kaks suunda lähevad läbi eri seadmete. Päring lahkub harust VPN-i kaudu, maandub NVA A-le ja jõuab töökoormuseni. Vastus lahkub töökoormusest, vastab NVA B-le osutavale marsruudile ja sureb seal. Iga marsruut sellel pildil on kehtiv ja TCP-seanss on ikka katki.

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

See lünk on siin kogu teema: marsruutimise konvergents ja seansi oleku omandiõigus on erinevad probleemid, mis diagrammil näivad identsed.

Mida Route Server tegelikult programmeerib

Azure Route Server loob peer-suhte toetatud BGP-kõnelejatega, õpib nende marsruudid ja programmeerib need virtuaalvõrgu efektiivsetesse marsruutidesse. See on juhtimistasandi töö. See ei loe müüja tulemüüri seansitabelit ega tea, milline seade ühe kindla ühenduse lubas. Kaks võrdse kuluga järgmist hüpet on selle kanga jaoks lihtsalt kaks viisi sama prefiksi saavutamiseks ja see kasutab kumbagi.

Marsruudi õppimine tõestab seega kättesaadavust. See ei tõesta midagi selle kohta, kas teises otsas olev seade on seda voogu varem näinud.

Lugege mõlemat suunda enne projekteerimist

Alustage sellest, et kirjutate üles juhtimise, mis teil tegelikult kummaski suunas on, mitte selle, mida kavatsesite. Spetsiifilisemad BGP-marsruudid, kasutaja määratud marsruudid ja lüüsi käitumine võistlevad kõik ning võitja otsustatakse sihtkoha, mitte seansi järgi. NVA vaikemarsruut ei tähenda, et iga privaatne prefiks sellest läbi läheb.

Kasulik kontroll on küsida ühe konkreetse töökoormuse IP kohta, millisele järgmisele hüppele kumbki suund laheneb. Kui vastuseks on kaks erinevat seadet, on teil asümmeetria probleem, olenemata sellest, kas see on juba ilmnenud.

Kus olek elab

Olekut jälgiv tulemüür lubab ühenduse ja hoiab tabelikirjet, mille võti on viisik. Vastus peab jõudma seadmeni, mis seda kirjet hoiab, või peab see seade oleku muul viisil hankima. Miski Azure'i andmetasandil ei edasta kirjet seadmete vahel. Kas liiklus suunatakse tagasi omanikule, või jagavad seadmed olekut müüja mehhanismi kaudu, või projekt ei tööta.

Seepärast ei ole kaks tervet NVA-d kontrollimise tervisekontroll. Tervis on kättesaadavus; kontrollimine on see, milline eksemplar seanssi hoiab.

Toetatud HA-mudelid ja mida igaüks lubab

Microsoft's guidance on Virtual WAN-i marsruutimiskavatsuse kohta kirjeldavad piiratud käitumist kahe rolliga ühenduvuse ja tulemüüriga NVA-de puhul, kus otsemarsruutimine võib mööda minna jaoturi tavalisest sümmeetrilisest jõustamisest. Lugege neid märkmeid valitud topoloogia piirangutena, mitte keeluna aktiiv-aktiivsetele projektidele. Müüja paar, mis sünkroonib olekut või juhib voo kaupa, võib olla toetatud. Võrdse kuluga paar, mis ei tee kumbagi, ei ole.

Seejärel määratlege, mis juhtub olemasolevate seanssidega, kui sõlm ebaõnnestub. Marsruutimise konvergents taastab kättesaadavuse uutele voogudele sekundite jooksul, samal ajal kui vana tulemüüri olek lihtsalt kaob. Kliendi taasühendus võib olla dokumenteeritud tulemus ja see on otsus, mis tuleb teha enne juhtumit, mitte selle ajal.

Mida testida, enne kui sellele usaldada

Test with inspection enabled and töökoormuse juurdepääsupoliitikaga paigas, sest kumbki neist võib asümmeetria varjata. Saatke uus volitatud voog mõlemas suunas ja kinnitage, et sama seade nägi mõlemat poolt. Seejärel käivitage pidev liiklus ja käivitage kinnitatud ülesiire, jälgides, kas loodud seansid jäävad püsima või ühenduvad uuesti.

Korreleerige iga voog seda käsitlenud seadmega. Paketipüük ühel NVA-l ei ütle teile peaaegu midagi, kui vastus ei tulnud kunagi sinna tagasi.

Lõpuks kirjutage plaan kolme eraldi reana: marsruutide omandiõigus, liikluse juhtimine ja seansi oleku omandiõigus. Projektid purunevad, kui kaks esimest on lahendatud ja kolmandat eeldatakse.