Azure VPNeko NATek ez ditu gainjarritako VNet helbideak konpontzen
Barruti pribatu bera duten bi VNet ez dira konektatuko NAT badagoelako soilik. Egiaztatu lehenengo konexio mota, eta gero zenbakitu berriro edo eduki itzulpen alias baten jabe.
Bi VNet-ek 10.40.1.0/24 erabiltzen dute, tunelek gora egiten dute, eta ezerk ez du funtzionatzen. Bigarren VPN atebide bat gehitzeak ez du hori aldatzen, ezta bide-metrika txikiago batek ere, arazoa ez baita bide hautaketa. Helbide pribatu berari erantzuten dioten bi lan-kargak pakete bakoitza helmuga anbiguoarekin eta egiaztatu ezin den itzulera-bidearekin uzten dute. Edozein itzulpen planifikatu aurretik, jakin ezazu benetan zein konexio mota sortu duzun, hautaketa bakar horrek erabakitzen baitu Azureko NAT funtzioa eskuragarri dagoen ala ez.
Zer ari zaizu esaten sintomak benetan
VNet A-ko ostalari batek 10.40.1.10 helbidera bidaltzen duenean, bideratze-taulak nonbait seinalatu baino ezin du. VNet B-k ere 10.40.1.10 badu, helbide hori ez da bideak bereiz dezakeen helmuga; bi jabe dituen helbide bakarra da.
Jendeak normalean hedatzen duen bigarren atebideak ez du laguntzen. Beste tunel bat ematen dizu, ez beste helbide bat, eta barruti bikoiztua tunelaren barruan aldatu gabe bidaiatzen du. Gainera, koherente mantendu behar duzun konfigurazioa bikoizten du. Ezin duena da helbide batek bi ostalari esan nahi izatea.
VPN kideen helbide publikoak aldatzeak ere ez du ezer egiten. Helbide horiek tunelaren muturrak identifikatzen dituzte, talka berriz barruan garraiatzen den barruti pribatuan dago.
Konexio motak erabakitzen du NAT eskuragarri dagoen
Azure VPN Gateway-k badu NAT gaitasuna, eta bideetan oinarritutako IPsec instalazio arteko konexioetarako dokumentatuta dago atebide SKU zehatzetan. Dokumentazio berak VNet-to-VNet eta point-to-site konexioak baztertzen ditu, beraz funtzioa ez da atebide-harreman guztietan agertzen den kontrol-lauki bat.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet natiboak ere eskatzen du VNet eta sare lokaleko barrutiek hasieratik gainjarri ez daitezen, bazterketarekin bat datorrena. VNet parekatzea ere ez da gainjartzearen irtenbidea arrazoi beragatik.
Badago lagundutako alternatiba bat jendeak mota natiboarekin nahasten duena: modelatu beste VNet sarea sare lokal gisa eta konektatu gunez guneko konexio gisa. Baliabide desberdina eta diseinu desberdina da, beraz tratatu berrizendatutako konexioa baliozkotu beharreko aldaketa gisa, ez izen-aldaketa hutsean.
Zenbakitu berriro, edo itzuli aliasaren jabe den zerbait erabiliz
Bi VNet-ak zureak badira, alderatu aurreikusitako berriz zenbakitzea itzulpenaren etengabeko kostuarekin. Berriz zenbakitzeak aplikazioen konfigurazioa, DNS erregistroak, segurtasun arauak eta lehendik dagoen konexio guztiak ukitzen ditu, baina gero normaltasunez irakurtzen den sare bat uzten du. Egin azpisare bat aldi berean, DNS aldaketa azkenik. Erdi-zenbakatutako barruti bat bi aukera baino okerragoa da, orduan bi aurrizkiak autoritarioak iruditzen baitzaizkio taula hurrengo irakurtzen duenari.
Berriz zenbakitzea praktikoa ez den lekuan, erabili itzulitako diseinu bat aliasaren benetako jabearekin. VNet A-ko deitzaileek VNet B-ren 10.40.1.10 helbidera 10.140.1.10 gisa iritsi daitezke, baina alias horrek itzultzen duen gailu bat, hara doan bide bat eta erantzunerako portaera baliokidea behar ditu. DNSan bakarrik gehitutako helbidea ez da itzulpen bat.
Erregistratu bi barrutiak bi norabideetan: deitzaileak zer markatzen duen, helmugak zer ikusten duen iturri gisa eta zein alde has daitekeen. Azureren NAT arauek beren SNAT mapatzeko alderantzizko itzulpena barne hartzen dute, beraz ez duzu eskuz DNAT arau baliokidea idazten, baina erosotasun hori funtzioak onartzen dituen konexio motetan amaitzen da.
Zerk ez du funtzionatuko
Erabiltzaileak definitutako bideak edo bide-metrikak ezin du falta den helbide-bereizketa sortu. Biek oraindik anbiguoa den helmuga bat dute hizpide, eta paketea taulak nahiago duen hurrengo jaukira iristen da.
Barruti bikoiztua aurrizki zehatzago gisa bide-taulari gehitzeak anbiguotasuna pauso bat soilik mugitzen du. Gainera, beste norabidea hausteko joera du, non erantzunak orain bi iturri sinesgarri dituen.
Onartu diseinua bi norabideetako trafikoarekin
Frogatu diseinua alde bakoitzeko baimendutako eragiketa berri batekin, ez tunelaren egoerarekin. Konektatutako IPsec tunel batek kideak kriptografia ados daudela esaten du; ez du ezer esaten helmugak bereizgarri bihurtu diren ala ez.
Ondoren exekutatu ukatutako bideak: iristezin egon behar duen helbide bat eta politikak blokeatu behar duen zerbitzu bat. Biak oraindik lortzen badira, itzulpena diseinuak nahi zuena baino zabalagoa da.
Itxi konfigurazioa geroago azaltzen duten datuekin: jatorrizko barrutia, aurkeztutako barrutia, itzultzen duen gailua eta alde bakoitzak has dezakeen norabidea. Horietako bat falta bada, hurrengo ingeniariak bi ostalarik izen bera partekatzen duten sare bat heredatzen du, eta inork ez du gogoratzen zergatik erantzuten duen batek.