Bi VPN helbide lokal: Azureko bi peer, bat ez
Bigarren VPN helbide lokal bat beste peer bat da, ez bigarren eremu-balio bat. Sare lokaleko ate bat eta konexio bat gailuko, gero zenbatu tunelak.
Diagramak bi internet-esteka ditu sukurtsalean eta Azure VPN ate bat, beraz sare lokaleko ateak bi helbide publikoak jasotzen ditu. Txukun dirudi, eta ez du diagramak iradokitzen duen bezala funtzionatzen. VPN gailu lokal bakoitza peer-harreman bereizia da, eta Microsoften gailu anitzeko diseinuak bakoitzari bere sare lokaleko ate baliabidea eta bere konexioa ematen dizkio. Baliabide bakarrari bigarren helbide bat gehitzeak ez du bigarren peer bat sortzen. Bi gailuetako bat ere behar bezala deskribatzen ez duen baliabidea sortzen du.
Mitoa: ate bat, bi helbide
Sare lokaleko atea urruneko peer baten deskribapena da: mutur publiko bat eta haren atzeko aurrizki pribatuak. Ez dago modu onarturik baliabide horrek «bi gailuetako edozein» esan dezan.
Etxekotasun berbera beste norabidean gertatzen da, non Azureko bi IP publiko Azureko bi ate daudelako froga gisa irakurtzen diren.
Zenbatu objektuak, gero tunelak
Hartu independenteki kudeatutako bi gailu lokal, bakoitza bere helbide publikoarekin eta sare pribatu berberetarako sarbidearekin, gehi bideratzean oinarritutako Azure ate bat aktibo-aktibo moduan. Azure ateak bi instantzia aktibo ditu IP publiko bereiziekin. Gailu lokal bakoitza bi instantziekin konektatzen da. Hori da sare osoa, eta objektu-kopurua hortik dator, ez diagramatik.
Aritmetika nahikoa laburra da diseinu-dokumentuan itsasteko:
2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh
Konexio-baliabide batek azpiko tunel bat baino gehiago eraman ditzake, beraz lau tunel ez dira lau sare birtualeko ate. Azureko bi IP publiko ere ez dira eremu urruneko gunea deskribatzen duten bi sare lokaleko ateen objektu berberak.
Zer gehitzen duen aktibo-aktiboak Azure aldean
Aktibo-aktiboak Azure atea instantzia aktibo batetik bitara aldatzen du, bakoitza bere IP publikoarekin, eta horrek egiten du sare osoa posible. Ez du fluxu bakarraren zeharkako ahalmena bikoizten. Ez du kentzen, halaber, alde lokalak kostu berdineko bide anizkoitza onartu behar izatea bi gailuek aldi berean birbidaltzen badute. Egiaztatu atearen modua, SKUa eta urruneko gailuaren gaitasuna ezer hornitu aurretik.
Itxarote pasiboko ate bat diseinu guztiz baliozkoa da; tunel-kopuru desberdina ematen du soilik.
BGPk bi bideak erabilgarri egiten ditu
Gailu anitzeko diseinurako, bi gailu lokalek BGP exekutatzen dute. Eman bakoitzari BGP peer helbide bakarra eta iragar itzazu aurreikusitako aurrizki pribatu berberak dagokien bideetan. Aurrizki pribatuek babestutako sareak identifikatzen dituzte, eta helbide publikoek konexio garraiatzaile zifratuak non amaitzen diren. Biak nahasteak tunel guztiak martxan eta bideak oker dauden diseinua sortzen du.
Planifikatu itzulera-bideratzea eta bi bideak edo edozein jasateko duen egoera-ikuskapena. Mutur bakoitzean IKE saio osasuntsu batek ez du frogatzen karga batek iragarritako bide guztiak erabil ditzakeenik.
Fluxuetan oinarritutako hautaketa ez da banda-zabaleraren bateratzea
Azurek fluxu bakoitzeko bide bat hautatzen du fluxuaren helbideratzearen eta portuen gaineko hash bat erabiliz. Egoera egonkorrean, TCP edo UDP fluxu jakin baten paketeek tunel bera hartzen dute normalean, eta alde lokalak beste tunel bat hauta dezake itzulera-norabiderako. Beraz, bi gailuk eta lau tunelek eskuragarritasuna hobetzen dute, ez transferentzia baten abiadura. Saltzailearen diapositiba batek agregazioa agintzen duenean, beste funtzio bat edo gaizki-ulertu bat deskribatzen ari da.
Probatu fluxu paraleloekin bideak nola banatzen diren ikusi nahi baduzu, eta fluxu bakarrarekin muga ikusi nahi baduzu.
Zein soberakin kendu duzun benetan
Gailu batean bi WAN helbidek sarbide-estekaren aukerak hobetzen dituzte, baina gailu horren elikadura, softwarea eta hutsegite-egoera partekatzen dituzte. Ez dira bi gailu bezalakoak, eta Azure aldeko konfigurazioak ez du hori aldatzen. Jarraitu saltzaileak onartzen duen WAN bikoitzeko edo klusterreko diseinua, helbide-kopurutik soberakina ondorioztatu beharrean. Gero probatu: kendu bide bat aldiko eta berretsi geratzen diren bideak eta bi norabideetako aplikazio-truke erreala.
Espero itzazu detekzio- eta konbergentzia-atzerapenak, eta espero itzazu lehendik dauden saio batzuk amaitzea.