Azure NVA-inspektado: kial la respondo pasas tra alia fajroŝirmilo

Fluo de filio al Azure povas esti ĝuste enkursigita en ambaŭ direktoj kaj tamen malsukcesi, ĉar la du direktoj prenas malsamajn aparatojn. La peto forlasas la filion tra la VPN, surteriĝas sur NVA A kaj atingas la laborŝarĝon. La respondo forlasas la laborŝarĝon, kongruas kun vojo indikanta al NVA B kaj mortas tie. Ĉiu vojo en tiu bildo estas valida, kaj la TCP-seanco ankoraŭ estas rompita.

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

Tiu manko estas la tuta temo ĉi tie: enkursiga kunverĝo kaj posedo de la seanca stato estas malsamaj problemoj, kiuj aspektas identaj en diagramo.

Kion Route Server efektive programadas

Azure Route Server kunligiĝas kun subtenataj BGP-parolantoj, lernas iliajn vojojn kaj programadas ilin en la efikajn vojojn de la virtuala reto. Tio estas laboro de la regada ebeno. Ĝi ne legas la seanctabelon de vendista fajroŝirmilo kaj ne havas ideon, kiu aparato akceptis donitan konekton. Du sekvaj saltoj de egala kosto estas, por tiu teksaĵo, simple du manieroj atingi la saman prefikson, kaj ĝi uzos ĉiun ajn.

Lerni vojon do pruvas atingeblon. Ĝi pruvas nenion pri tio, ĉu la aparato ĉe la alia fino jam vidis ĉi tiun fluon.

Legi ambaŭ direktojn antaŭ ol desegni

Komencu per skribi la direktadon, kiun vi efektive havas en ĉiu direkto, ne tiun, kiun vi intencis. Pli specifaj BGP-vojoj, uzant-difinitaj vojoj kaj pordego-konduto ĉiuj konkuras, kaj la venkanto decidiĝas por ĉiu celo, ne por ĉiu seanco. Defaŭlta vojo sur NVA ne signifas, ke ĉiu privata prefikso trapasas ĝin.

Utila kontrolo estas demandi, por unu specifa laborŝarĝa IP, al kiu sekva salto ĉiu direkto solviĝas. Se la respondo estas du malsamaj aparatoj, vi havas asimetrian problemon, ĉu ĝi jam aperis aŭ ne.

Kie loĝas la stato

Stathava fajroŝirmilo akceptas konekton kaj tenas tabelan enskribon ŝlositan per la kvinopo. La respondo devas atingi la aparaton tenantan tiun enskribon, aŭ tiu aparato devas akiri la staton alimaniere. Nenio en la datumebeno de Azure plusendas la enskribon inter aparatoj. Aŭ la trafiko estas direktata reen al la posedanto, aŭ la aparatoj kunhavas staton per vendista mekanismo, aŭ la dezajno ne funkcias.

Tial du sanaj NVA-oj ne estas sankontrolo por inspektado. Sano temas pri atingeblo; inspektado temas pri tio, kiu kazo tenas la seancon.

Subtenataj HA-modeloj kaj kion ĉiu promesas

Microsoft's guidance on la enkursiga intenco de Virtual WAN priskribas limigitan konduton por duobla-roja konekteco kaj fajroŝirmilaj NVA-oj, kie rekta enkursigado povas preterpasi la normalan simetrian trudon de la hubo. Legu tiujn notojn kiel limigojn al la elektita topologio, ne kiel malpermeson de aktiv-aktivaj dezajnoj. Vendista paro, kiu sinkronigas staton aŭ direktas laŭ fluo, povas esti subtenata. Paro de egala kosto, kiu faras nek unu nek la alian, ne estas.

Poste difinu, kio okazas al ekzistantaj seancoj kiam nodo paneas. Enkursiga kunverĝo restarigas atingeblon por novaj fluoj ene de sekundoj, dum la malnova fajroŝirmila stato simple malaperis. Klienta rekonigo povas esti la dokumentita rezulto, kaj tio estas decido farota antaŭ la okazaĵo, ne dum ĝi.

Kion testi antaŭ ol fidi ĝin

Test with inspection enabled and la alirpolitiko de la laborŝarĝo en loko, ĉar ĉiu el ili povas kaŝi la asimetrion. Sendu novan rajtigitan fluon en ambaŭ direktoj kaj konfirmu, ke la sama aparato vidis ambaŭ duonojn. Poste rulu daŭran trafikon kaj ekigu la aprobitan malsukcesotransiron, observante, ĉu establitaj seancoj postvivas aŭ rekonektiĝas.

Korelaciu ĉiun fluon kun la aparato, kiu traktis ĝin. Paketkapto sur unu NVA diras al vi preskaŭ nenion, se la respondo neniam revenis al ĝi.

Fine, skribu la planon kiel tri apartajn liniojn: posedo de vojoj, direktado de trafiko kaj posedo de seanca stato. Dezajnoj rompiĝas, kiam la unuaj du estas solvitaj kaj la tria estas supozata.