NVA-skoðun í Azure: hvers vegna svar fer í gegnum aðra eldvegg

Flæði frá útibúi til Azure getur verið beint rétt í báðar áttir og samt mistekist, því báðar áttir fara um ólík tæki. Beiðnin yfirgefur útibúið um VPN, lendir á NVA A og nær vinnuálaginu. Svarið yfirgefur vinnuálagið, passar við leið sem bendir á NVA B og deyr þar. Sérhver leið á þeirri mynd er gild, og TCP setan er samt brotin.

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

Þetta bil er allt umræðuefnið hér: leiðasamleitni og eignarhald á setuástandi eru ólík vandamál sem líta eins út á skýringarmynd.

Hvað Route Server forritar í raun

Azure Route Server myndar peer-tengingu við studda BGP-raddara, lærir leiðir þeirra og forritar þær í virkar leiðir sýndarnetsins. Þetta er verk í stjórnlaginu. Það les ekki setutöflu eldveggs frá seljanda og hefur ekki hugmynd um hvaða tæki leyfði tiltekna tengingu. Tvö næstu hopp með jöfnum kostnaði eru, fyrir þetta efni, einfaldlega tvær leiðir til að ná sama forskeyti, og það mun nota hvora sem er.

Að læra leið sannar því aðgengi. Það sannar ekkert um hvort tækið hinum megin hafi séð þetta flæði áður.

Lestu báðar áttir áður en þú hannar

Byrjaðu á að skrifa niður stýringuna sem þú hefur í raun í hvorri átt, ekki þá sem þú ætlaðir. Nákvæmari BGP-leiðir, notandaskilgreindar leiðir og hegðun gáttar keppa allar, og sigurvegarinn er ákveðinn fyrir hvert áfangastað, ekki fyrir hverja setu. Sjálfgefin leið á NVA þýðir ekki að hvert einkaforskeyti fari í gegnum hana.

Gagnleg athugun er að spyrja, fyrir eitt tiltekið vinnuálags-IP, hvaða næsta hopp hver átt leysist í. Ef svarið er tvö ólík tæki hefur þú ósamhverfu vandamál, hvort sem það hefur komið í ljós eða ekki.

Hvar ástandið býr

Eldveggur með ástandi leyfir tengingu og heldur töflufærslu sem er lykluð á fimmundanum. Svarið verður að ná til tækisins sem heldur þeirri færslu, eða það tæki verður að fá ástandið á annan hátt. Ekkert í gagnasviði Azure sendir færsluna milli tækja. Annaðhvort er umferðinni beint aftur til eigandans, eða tækin deila ástandi gegnum fyrirkomulag seljanda, eða hönnunin virkar ekki.

Þess vegna eru tvö heilbrigð NVA ekki heilsufarsathugun fyrir skoðun. Heilsa snýst um aðgengi; skoðun snýst um hvaða tilvik heldur setunni.

Studdar HA-líkanir og hvað hver lofar

Microsoft's guidance on leiðabeiningu Virtual WAN lýsir afmörkuðu atferli fyrir tvíhlutverka tengingu og eldveggs-NVA, þar sem bein leiðsla getur farið fram hjá venjulegri samhverfri framfylgd hubsins. Lestu þessar athugasemdir sem takmarkanir á þeirri grannfræði sem þú valdir, ekki sem bann við virkum-virkum hönnunum. Seljandapar sem samstillir ástand, eða stýrir eftir flæði, getur verið stutt. Jafn kostnaðar par sem gerir hvorugt er það ekki.

Skilgreindu síðan hvað verður um núverandi setur þegar hnútur bregst. Leiðasamleitni endurheimtir aðgengi fyrir ný flæði innan sekúndna, á meðan gamla eldveggsástandið er einfaldlega farið. Endurtenging biðlarans gæti verið skjalfesta niðurstaðan, og það er ákvörðun sem á að taka fyrir atvikið, ekki á meðan.

Hvað á að prófa áður en þú treystir því

Test with inspection enabled and aðgangsstefnu vinnuálagsins á sínum stað, því hvorugt getur falið ósamhverfuna. Sendu nýtt heimilað flæði í báðar áttir og staðfestu að sama tækið hafi séð báða helmingana. Keyrðu síðan viðvarandi umferð og virkjaðu samþykktu yfirfærsluna, og fylgstu með hvort komnar setur lifi af eða tengist aftur.

Tengdu hvert flæði við tækið sem annaðist það. Pakkanám á einu NVA segir þér næstum ekkert ef svarið kom aldrei þangað aftur.

Að lokum, skrifaðu áætlunina sem þrjár aðskildar línur: eignarhald leiða, stýring umferðar og eignarhald setuástands. Hönnun brotnar þegar fyrstu tvær eru leystar og þriðja er gert ráð fyrir.