Azure NVA -tarkastus: miksi vastaus kulkee toisen palomuurin kautta

Haarasta Azureen suuntautuva virtaus voidaan reitittää oikein molempiin suuntiin ja silti epäonnistua, koska kaksi suuntaa kulkevat eri laitteiden kautta. Pyyntö lähtee haarasta VPN:n yli, laskeutuu NVA A:lle ja saavuttaa työkuorman. Vastaus lähtee työkuormasta, osuu NVA B:hen osoittavaan reittiin ja kuolee sinne. Jokainen reitti kuvassa on kelvollinen, ja TCP-istunto on silti rikki.

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

Tämä aukko on koko aihe täällä: reitityksen konvergenssi ja istunnon tilan omistajuus ovat eri ongelmia, jotka näyttävät kaaviossa samoilta.

Mitä Route Server oikeastaan ohjelmoi

Azure Route Server solmii peer-suhteen tuettuihin BGP-puhujiin, oppii niiden reitit ja ohjelmoi ne virtuaaliverkon tehokkaisiin reitteihin. Se on ohjaustason työ. Se ei lue toimittajan palomuurin istuntotaulua eikä tiedä, mikä laite päästi tietyn yhteyden läpi. Kaksi yhtä suurta seuraavaa hyppyä ovat tälle kudokselle yksinkertaisesti kaksi tapaa saavuttaa sama etuliite, ja se käyttää kumpaa tahansa.

Reitin oppiminen todistaa siis tavoitettavuuden. Se ei todista mitään siitä, onko toisen pään laite nähnyt tämän virtauksen aiemmin.

Lue molemmat suunnat ennen suunnittelua

Aloita kirjoittamalla ohjaus, joka sinulla todella on kussakin suunnassa, ei se, jonka aioit. Tarkemmat BGP-reitit, käyttäjän määrittämät reitit ja yhdyskäytävän käyttäytyminen kilpailevat kaikki, ja voittaja ratkaistaan kohdekohtaisesti, ei istuntokohtaisesti. NVA:n oletusreitti ei tarkoita, että jokainen yksityinen etuliite kulkee sen kautta.

Hyödyllinen tarkistus on kysyä yhdeltä tietyltä työkuorman IP-osoitteelta, mihin seuraavaan hyppyyn kumpikin suunta ratkeaa. Jos vastaus on kaksi eri laitetta, sinulla on epäsymmetriaongelma riippumatta siitä, onko se jo tullut esiin.

Missä tila asuu

Tilallinen palomuuri päästää yhteyden ja pitää taulumerkintää, jonka avain on viisikko. Vastauksen on saavutettava laite, jolla tämä merkintä on, tai laitteen on hankittava tila jollain muulla tavalla. Mikään Azuren datatasossa ei välitä merkintää laitteiden välillä. Joko liikenne ohjataan takaisin omistajalle, tai laitteet jakavat tilan toimittajan mekanismin kautta, tai suunnittelu ei toimi.

Siksi kaksi tervettä NVA:ta ei ole tarkastuksen terveystarkistus. Terveys koskee tavoitettavuutta; tarkastus koskee sitä, mikä instanssi pitää istuntoa.

Tuetut HA-mallit ja mitä kukin lupaa

Microsoft's guidance on Virtual WAN -reititysaikeesta kuvaa rajattua käyttäytymistä kaksoisrooliyhteydelle ja palomuurin NVA:ille, joissa suora reititys voi ohittaa hubin normaalin symmetrisen valvonnan. Lue nämä huomautukset valitun topologian rajoituksina, älä aktiivis-aktiivisten suunnitelmien kieltona. Toimittajapari, joka synkronoi tilan tai ohjaa virtauskohtaisesti, voidaan tukea. Yhtä suuri pari, joka ei tee kumpaakaan, ei ole.

Määrittele sitten, mitä olemassa oleville istunnoille tapahtuu, kun solmu epäonnistuu. Reitityksen konvergenssi palauttaa tavoitettavuuden uusille virtauksille sekunneissa, kun taas vanha palomuurin tila on yksinkertaisesti poissa. Asiakkaan uudelleenyhteys voi olla dokumentoitu lopputulos, ja se on päätös, joka tehdään ennen tapahtumaa, ei sen aikana.

Mitä testata ennen kuin siihen luottaa

Test with inspection enabled and työkuorman käyttöoikeuskäytäntö paikallaan, koska kumpi tahansa voi piilottaa epäsymmetrian. Lähetä uusi valtuutettu virtaus molempiin suuntiin ja varmista, että sama laite näki molemmat puoliskot. Aja sitten jatkuvaa liikennettä ja käynnistä hyväksytty failover ja seuraa, säilyvätkö vakiintuneet istunnot vai yhdistyvätkö ne uudelleen.

Korreloi jokainen virtaus sen käsitelleen laitteen kanssa. Yhden NVA:n pakettikaappaus ei kerro juuri mitään, jos vastaus ei koskaan palannut sinne.

Kirjoita lopuksi suunnitelma kolmeen erilliseen riviin: reittien omistajuus, liikenteen ohjaus ja istunnon tilan omistajuus. Suunnitelmat hajoavat, kun kaksi ensimmäistä on ratkaistu ja kolmas oletetaan.