Azure NVA pārbaude: kāpēc atbilde iet caur citu ugunsmūri

Plūsma no filiāles uz Azure var tikt maršrutēta pareizi abos virzienos un tomēr neizdoties, jo abi virzieni iet caur dažādām ierīcēm. Pieprasījums atstāj filiāli pa VPN, nolaižas uz NVA A un sasniedz darba slodzi. Atbilde atstāj darba slodzi, atbilst maršrutam, kas norāda uz NVA B, un tur mirst. Katrs maršruts šajā attēlā ir derīgs, un TCP sesija joprojām ir salauzta.

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

Šī plaisa šeit ir visa tēma: maršrutēšanas konverģence un sesijas stāvokļa piederība ir dažādas problēmas, kas diagrammā izskatās identiskas.

Ko Route Server faktiski programmē

Azure Route Server izveido peering ar atbalstītiem BGP runātājiem, apgūst viņu maršrutus un programmē tos virtuālā tīkla efektīvajos maršrutos. Tas ir vadības plaknes darbs. Tas nelasa pārdevēja ugunsmūra sesiju tabulu un nezina, kura ierīce pieļāva konkrētu savienojumu. Divi vienādas izmaksas nākamie lēci šim audumam ir vienkārši divi veidi, kā sasniegt to pašu prefiksu, un tas izmantos jebkuru.

Tādējādi maršruta apgūšana pierāda sasniedzamību. Tā neko nepierāda par to, vai ierīce otrā galā šo plūsmu jau ir redzējusi.

Izlasiet abus virzienus pirms projektēšanas

Sāciet ar to, ka pierakstāt vadību, kas jums patiešām ir katrā virzienā, nevis to, ko bijāt iecerējis. Konkrētāki BGP maršruti, lietotāja definēti maršruti un vārtejas uzvedība visi konkurē, un uzvarētājs tiek noteikts pēc galamērķa, nevis pēc sesijas. Noklusējuma maršruts uz NVA nenozīmē, ka katrs privātais prefikss iet caur to.

Noderīga pārbaude ir pajautāt, vienai konkrētai darba slodzes IP, uz kuru nākamo lēcienu atrisinās katrs virziens. Ja atbilde ir divas dažādas ierīces, jums ir asimetrijas problēma neatkarīgi no tā, vai tā jau ir parādījusies.

Kur dzīvo stāvoklis

Stāvokļa ugunsmūris pieņem savienojumu un glabā tabulas ierakstu ar atslēgu uz piecinieku. Atbildei jāsasniedz ierīce, kurai ir šis ieraksts, vai arī šai ierīcei stāvoklis jāiegūst citādi. Nekas Azure datu plaknē nepārsūta ierakstu starp ierīcēm. Vai nu trafiks tiek novirzīts atpakaļ īpašniekam, vai ierīces dala stāvokli ar pārdevēja mehānismu, vai arī dizains nedarbojas.

Tāpēc divi veseli NVA nav pārbaudes veselības pārbaude. Veselība ir par sasniedzamību; pārbaude ir par to, kura instance tur sesiju.

Atbalstītie HA modeļi un ko katrs sola

Microsoft's guidance on Virtual WAN maršrutēšanas nodomu apraksta ierobežotu uzvedību divu lomu savienojamībai un ugunsmūra NVA, kur tiešā maršrutēšana var apiet parasto huba simetrisko izpildi. Lasiet šīs piezīmes kā ierobežojumus izvēlētajai topoloģijai, nevis kā aktīvu-aktīvu dizainu aizliegumu. Pārdevēja pāris, kas sinhronizē stāvokli vai vada pēc plūsmas, var tikt atbalstīts. Vienādas izmaksas pāris, kas nedara ne vienu, ne otru, netiek.

Pēc tam definējiet, kas notiek ar esošajām sesijām, kad mezgls sabojājas. Maršrutu konverģence atjauno sasniedzamību jaunām plūsmām sekunžu laikā, bet vecais ugunsmūra stāvoklis vienkārši pazūd. Klienta atkārtots savienojums var būt dokumentētais rezultāts, un tas ir lēmums, kas jāpieņem pirms incidenta, nevis tā laikā.

Kas jāpārbauda, pirms tam uzticēties

Test with inspection enabled and darba slodzes piekļuves politiku vietā, jo jebkura no tām var paslēpt asimetriju. Nosūtiet jaunu atļautu plūsmu abos virzienos un apstipriniet, ka tā pati ierīce redzēja abas puses. Pēc tam palaidiet pastāvīgu trafiku un iedarbiniet apstiprināto pārslēgšanu, vērojot, vai izveidotās sesijas izdzīvo vai atkārtoti savienojas.

Korelējiet katru plūsmu ar ierīci, kas to apstrādāja. Pakešu uztveršana vienā NVA gandrīz neko nepasaka, ja atbilde nekad neatgriezās tur.

Visbeidzot, uzrakstiet plānu trīs atsevišķās rindās: maršrutu piederība, trafika vadība un sesijas stāvokļa piederība. Dizaini lūzt, kad pirmie divi ir atrisināti un trešais tiek pieņemts.