Bi sukurtsalen arteko trafikoa Azure VPN atebide baten bidez bideratzea
Azure VPN atebide bakarreko bi Site-to-Site konexioek sukurtsalen trafikoa pasa dezakete, baina soilik bi muturrek prefijoa ikasten dutenean eta LANeko itzulera-bidea badagoenean.
Bi sukurtsalek trafikoa truka dezakete Azure VPN atebide baten bidez, haien artean tunel zuzenik gabe. Sukurtsal bakoitzak Site-to-Site konexio bat irekitzen du ate berarekin, eta ateak ikasitako prefijoak pasatzen ditu bi konexioen artean. Hau funtzional egiten duena ez da bigarren tunela, ibilbide-trukea baizik: A sukurtsalak B sukurtsalaren prefijoa ikasi behar du, eta Bk A-rena. Jarraitu beheko egiaztapenak ordenan eta gelditu huts egiten duen lehenenean, geroagoko urrats bakoitza hartatik baitago.
Aurrebaldintzak, ezer konfiguratu aurretik
Lau baldintzak erabakitzen dute diseinu honek funtziona dezakeen ala ez. Ateak ibilbideetan oinarrituta egon behar du eta BGP onartzen duen SKU batean egon behar du, bi konexioek BGP gaituta izan behar dute, sukurtsalen helbide-espazioek ez dute gainjarri behar, eta inongo aldek ez du NAT-en menpe egon behar bere benetako prefijoa ezkutatzeko.
Plangintza ezazu ASNak kontzienteki. Azurek dokumentatutako balio lehenetsia 65515 da, eta sukurtsal bakoitzeko bideratzaileak bere ASN pribatua behar du, atearekin edo beste sukurtsalarekin talka ez dezan. Balio lehenetsi bat berrerabiltzea lehendik dagoen atearen konfigurazioa egiaztatu gabe da AS ibilbide bat geroago baztertzen den modua.
Egiaztatu halaber ez duzula VNet parekatzearen portaera espero. Ateak konfiguratu dituzun bi konexioen artean trukatzen ditu ibilbideak; ez ditu parekatze arbitrarioak trantsitibo bihurtzen. Hirugarren sare batek bi sukurtsalak iritsi behar baditu, bere konexioa edo bere ibilbide-bidea behar du, ez atea trafikoa zabalduko duen ustea. Idatzi muga hori lehen aldaketa-leihoaren aurretik, geroago gune bat gehitzean jendeak berriro hartzen duen diseinu-erabakia baita.
Konfiguratu ordena honetan
Urrats bakoitzak behatu daitekeen emaitza du, beraz ez jarraitu agertu arte.
- Gaitu BGP sare birtualeko atean eta idatzi haren ASNa eta pareko helbidea.
- Sortu sare lokaleko ate bat sukurtsal bakoitzeko, sukurtsal horren benetako helbide-espazioarekin, haren ASNarekin eta BGP pareko helbidearekin.
- Sortu Site-to-Site konexio bakoitza eta gaitu BGP konexioan bertan.
- Konfiguratu sukurtsaleko bideratzailea Azurek esleitutako ate-helbidearekin parekatzeko, ez atearen IKE amaiera publikoarekin ustez.
Laugarren urratsa da saiakerarik gehienak trabatzen diren lekua. Azurek jakinarazten duen BGP pareko helbidea sukurtsaleko bideratzaileak bizilagun gisa erabili behar duena da, eta ez da beti jendeak tunelaren diagramatik espero duen helbidea.
Iragarri sukurtsalaren prefijoa bera, adibidez 10.10.0.0/16 A-tik eta 10.20.0.0/16 B-tik. Ez iragarri ibilbide lehenetsirik ezta agregatu zabalik falta den sare jakin bat estaltzeko; hutsunea geroago zulo beltz isil gisa itzultzen da.
Egiaztatu ibilbide-trukea bi muturretan
Konexioaren egoera ez da egiaztapena. IPsec bi konexioetan aktibo egon daiteke haien artean prefijo bakar bat ere pasatzen ez dela. Irakurri atearen BGP parekoak eta ikasitako ibilbideak, eta gero egiaztatu beste sukurtsalaren norako ibilbidea erabilgarri gisa agertzen dela.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP taulan dagoen prefijo batek aurreratze-erabakia gal dezake oraindik ibilbide estatiko baten edo prefijo zehatzago baten aurrean. Egiaztatu hautatutako ibilbidea, ez soilik jasotakoa.
Jarraitu itzulera-bidea LAN aldean
Hau da Azuren zuzena dirudien eta tokian huts egiten duen zatia. A sukurtsaleko ostalari batek bere paketea A-ren VPN bideratzailera bidaltzen du, bideratzaile hori bere ate lehenetsia bada edo ostalariak edo haren ateak B-ren prefijoaren ibilbidea badu soilik. Alderantziz ere berdin gertatu behar da.
Nukleo-etengailu bereizi bat LANeko ate lehenetsia bada, beste sukurtsalaren norako ibilbidea behar du VPN bideratzailera seinalatuz. Hori gabe, eskaera iristen da eta erantzuna interneteko bideetatik irteten da, eta erabiltzaileak irekitzen den eta gero zintzilik geratzen den konexio bat ikusten du.
Ez jo atearen azpisareko sare-segurtasun talde batera hau konpontzeko. Azpisare horrek bere baldintzak ditu eta han NSG bat ez da sukurtsal aldeko politikaren ordezko onartua. Iragazketa sukurtsalen suebakietan eta karga-lanetan bertan dagokie, non arauak haien jabeek berrikus ditzaketen. Arau horiek azpisareko NSG batera eramateak hurrengo etenaldia araztuko duen taldetik ere ezkutatzen ditu.
Onartu eragiketa, eta gero frogatu ukatuako proba batekin
Ikasitako ibilbide bat ez da baimena. Onartu benetan behar duzun iturburua, helmuga eta zerbitzua sukurtsalen suebakien eta amaierako puntuaren politikaren bidez, eta utzi gainerakoa ukatuta.
Probatu A sukurtsaleko karga-lan arrunt batetik B sukurtsaleko zerbitzu erreal batera, egiaztatu erantzuna, eta gero saiatu debekatuta egon behar duen eragiketa bat. VPN gailuak berak sortutako trafikoak iturburu-helbide desberdina erabil dezake eta LAN bideratze-fasea saltatu, beraz bideratzailetik egindako ping arrakastatsu batek dirudiena baino gutxiago frogatzen du.
Amaitu lau gertaera idatziz: trukatutako prefijoak, erabilitako ASNak, alde bakoitzaren LAN itzulera-bidea eta zerbitzua onartzen duen politika. Horietako bat falta bada, konfigurazioak lehen aldaketara arte funtzionatzen du, eta orduan inork ezin du azaldu zergatik.