Pregled NVA v Azure: zakaj odgovor gre skozi drugo požarno zapore

Tok od podružnice do Azurea je lahko pravilno usmerjen v obe smeri in vseeno ne uspe, ker gresta obe smeri skozi različne naprave. Zahteva zapusti podružnico prek VPN, pristane na NVA A in doseže delovno obremenitev. Odgovor zapusti delovno obremenitev, se ujema s potjo, ki kaže na NVA B, in tam umre. Vsaka pot na tej sliki je veljavna, seja TCP pa je še vedno prekinjena.

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

Ta vrzel je tu celotna tema: konvergenca usmerjanja in lastništvo stanja seje sta različna problema, ki na diagramu izgledata enako.

Kaj Route Server dejansko programira

Azure Route Server vzpostavi peering s podprtimi govorci BGP, se nauči njihovih poti in jih programira v učinkovite poti virtualnega omrežja. To je delo krmilne ravnine. Ne bere tabele sej požarnega zidu ponudnika in ne ve, katera naprava je dovolila določeno povezavo. Dva naslednja skoka z enako ceno sta za to tkanino preprosto dva načina doseganja istega prefiksa in uporabil bo katerega koli.

Učenje poti torej dokazuje dosegljivost. Ne dokazuje ničesar o tem, ali je naprava na drugem koncu ta tok že videla.

Preberite obe smeri, preden oblikujete

Začnite s tem, da zapišete usmerjanje, ki ga v resnici imate v vsaki smeri, ne tistega, ki ste ga nameravali. Bolj specifične poti BGP, uporabniško določene poti in vedenje prehoda vsi tekmujejo, zmagovalec pa se odloči za vsak cilj, ne za vsako sejo. Privzeta pot na NVA ne pomeni, da gre skozi njo vsak zasebni prefiks.

Koristen pregled je vprašati za en določen IP delovne obremenitve, na kateri naslednji skok se razreši vsaka smer. Če sta odgovor dve različni napravi, imate problem asimetrije, ne glede na to, ali se je že pokazal.

Kje živi stanje

Požarni zid s sledenjem stanja sprejme povezavo in hrani vnos tabele s ključem petorke. Odgovor mora priti do naprave, ki ima ta vnos, ali pa mora ta naprava stanje pridobiti drugače. Nič v podatkovni ravnini Azure ne posreduje vnosa med napravami. Ali je promet usmerjen nazaj k lastniku, ali si naprave delijo stanje prek mehanizma ponudnika, ali zasnova ne deluje.

Zato dve zdravi NVA nista zdravstveni pregled za inšpekcijo. Zdravje je o dosegljivosti; inšpekcija je o tem, kateri primerek ima sejo.

Podprti modeli HA in kaj vsak obljublja

Microsoft's guidance on namenu usmerjanja Virtual WAN opisujejo omejeno vedenje za povezljivost z dvojno vlogo in požarne NVA, kjer lahko neposredno usmerjanje obide običajno simetrično uveljavljanje zvezdišča. Te zapiske berite kot omejitve izbrane topologije, ne kot prepoved aktivno-aktivnih zasnov. Par ponudnika, ki sinhronizira stanje ali usmerja po toku, je lahko podprt. Par z enako ceno, ki ne počne niti enega, ni.

Nato določite, kaj se zgodi z obstoječimi sejami, ko vozlišče odpove. Konvergenca poti obnovi dosegljivost za nove tokove v nekaj sekundah, medtem ko staro stanje požarnega zidu preprosto izgine. Ponovna povezava odjemalca je lahko dokumentiran izid in to je odločitev, ki jo sprejmete pred incidentom, ne med njim.

Kaj preizkusiti, preden mu zaupate

Test with inspection enabled and pravilnikom dostopa delovne obremenitve na mestu, ker lahko kateri koli od njiju skrije asimetrijo. Pošljite nov dovoljen tok v obe smeri in potrdite, da je ista naprava videla obe polovici. Nato zaženite trajni promet in sprožite odobreni preklop, ter opazujte, ali uveljavljene seje preživijo ali se znova povežejo.

Vsak tok povežite z napravo, ki ga je obdelala. Zajem paketov na enem NVA vam ne pove skoraj ničesar, če se odgovor nikoli ni vrnil tja.

Na koncu zapišite načrt kot tri ločene vrstice: lastništvo poti, usmerjanje prometa in lastništvo stanja seje. Zasnove se zlomijo, ko sta prvi dve rešeni, tretje pa predpostavljeno.