Azure UDR bat VPN atebide batera: helmuga bakarra, irteera osoa ez
Zuzendu Azure prefikso bat VPN atebidera irteera osoa mugitu gabe. Irakurri bide eraginkorrak, lotu karga-lanaren azpisarea eta amaitu itzulera-bidea.
Kanpoko prefikso bakarrerako erabiltzaileak definitutako bide bat gehitzen duzu, VPN atebidera zuzentzen duzu, eta trafikoak Azure-ren internet bidea erabiltzen jarraitzen du. Edo behar bezala irteten da eta erantzuna ez da inoiz itzultzen. Bi emaitzak errore beretik datoz: Azure-ko hurrengo jauzia diseinu osoa dela pentsatzea. Bide-taulak Azure barruan paketeak zein irteera hartzen duen baino ez du erabakitzen. Tunelaren ondoren harekin zer gertatzen den eta erantzuna nola itzultzen den eraiki behar duzun bigarren erdia da.
Hurrengo jauzia atebide bat da, ez gailu baten IPa
UDR batek bat datorren prefijoa hurrengo jauziko mota batera bidaltzen du, eta VirtualNetworkGateway mota bat da, ez helbide bat. Jendeak atebidearen IP pribatua VirtualAppliance bide batean itsasten du eta gero galdetzen du zergatik ez duen ezer bat egiten, mota horrek NIC bat edo barne karga-balantzagailu bat espero baitu. Microsoft-en bideratze dokumentazioak atebidearen hurrengo jauzia VPN atebidea duen sare birtualetara mugatzen du. ExpressRoute, Route Server eta Virtual WAN hub bat ez dira aukera horrekin helbideratzen.
Egiaztatu sare birtualak benetan zer duen bidea idatzi aurretik. Diseinuak hub baten bidez bideratzen badu, bidea hubaren bideratze-jabearena da, ez editatzeko duzun spokearena.
Irakurri bide eraginkorra ezer aldatu aurretik
Azure-k sistema-bideak, BGP bidez ikasitako prefijoak eta UDRak NIC bakoitzeko bide-taula eraginkor batean konbinatzen ditu, eta bat datorren prefijo luzeenak irabazten du nondik datorren kontuan hartu gabe. Prefijo bererako, UDR batek BGP bide bat gainditzen du. Ordena hori da aurreko esperimentu bateko UDR zaharkitu batek tunelaren bidez berriki ikasitako prefijoa isilean gaindi dezakeen arrazoia.
Begiratu lehenik taula eraginkorra, gero erabaki bide bat gehitzen duzun edo bat ordezkatzen duzun:
az network nic show-effective-route-table \
--resource-group rg-net --name vm-web-nic -o tableIrakurri iturri-zutabea ere, ez prefijoa soilik. Prefijo zuzena eta iturri okerra dituen bide batek zein objektu editatu behar duzun esaten dizu, eta lehenari galtzen dion bigarren bide bat gehitzetik salbatzen zaitu.
Idatzi bidea benetako prefijoari eta azpisareari egokituta
Erabili helmugaren benetako prefijoa, benetan heltzen zaren zerbitzutik hartua, foroko mezu batetik kopiatutako barruti publiko baten ordez. Hasi onartutako zerbitzu batekin irteera osoa mugitzen duen bide lehenetsia aztertu aurretik. Ondoren erantsi bide-taula karga-lanaren azpisareari. Atebidearen azpisareak bere baldintzak ditu, eta zure taula han erantsiz atebidea apurtzen duzu karga bideratu beharrean.
Sortu bidea, gero lotu taula karga jasotzen duen azpisareari:
az network route-table route create --resource-group rg-net --route-table-name rt-egress \
--name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
--name snet-web --route-table rt-egressHedapenak ere badu garrantzia. Taula horretan BGP hedapena gaituta dagoela, ikasitako prefijoak zuk idatzitakoen ondoan agertzen dira, eta ikasitako prefijo zehatzago batek UDR zabalago bat irabaz dezake. Desgaitu hedapena UDR multzoa azpisare horretarako agintaritza izan dadin nahi duzunean bakarrik.
Amaitu tokiko erdia edo fluxua bertan hiltzen da
Tokiko atebideak Azure iturria onartu behar du, helmugara bidali eta aplikazioa baimendu. Bere hurrengo bidea internet irteera edo beste jauzi pribatu bat izan daiteke, baina erabaki hori planean dago, ez Azure bide-taulan. Ohiko hutsegitea itzulera da. Interneteko helmuga batek ez du Azure iturri pribatu bat zuregana bideratuko, beraz erantzuna bere atebide lehenetsira doa eta hiltzen da, edo ez da inoiz irteten.
Bi diseinuk konpontzen dute hori eta ez dira trukagarriak. Itzuli iturria irteeran, helmugak tokiko sareak duen helbide publiko bati erantzun diezaion. Edo gorde iturria eta eraiki itzulera-harreman bideratua, erantzunak tunelaren bidez itzul daitezen. Aukeratu bat eta idatzi aplikazioak zein helbide ikusiko duen.
Hautatzaileak eta baimendutako zerrendak horretatik guztitik bereizita daude. Azure hurrengo jauzi bat aukeratzeak ez ditu VPN trafiko-hautatzaileak zabaltzen eta ez du kanpoko zerbitzu baten iturri-baimen zerrenda aldatzen.
Egiaztatu helmugak ikusitako iturriarekin
Bidali eskaera benetako karga-lanetik, ez beste azpisare bateko jauzi-makinatik, eta gero irakurri helmugak ikusi duen iturri-helbidea. Balio bakar horrek esaten dizu bi itzulera-diseinuetatik zein dagoen ezarrita. Ondoren egiaztatu erantzun-bidea eta berretsi VMrako ohiko kudeaketa-trafikoak oraindik funtzionatzen duela, istripuz gehitutako bide lehenetsi bat SSH saio hautsita gisa agertzen baita aplikazio hautsita gisa baino askoz lehenago.
Hautatutako prefijo baten bidezko transitak indartutako tunelatzea baino aldaketa askoz estuagoa da. Eutsi estua eta atzera-egitea bide bat ezabatzea da.