Azure P2S VPN ezin du amaiera-puntu pribatu baten izena ebatzi

Point-to-site tunela konektatu, helbide pribatuari ping egin, aplikazioa ireki eta horren ordez 403 bat edo ziurtagiri-errore bat jasotzen duzu. Bi sintomek DNSera eramaten dute, baina matxura desberdinak dira: batek esan nahi du bezeroak helbide publikoa ebatzi zuela, besteak helbide pribatua ebatzi eta gero ziurtagiriak estaltzen ez duen izen bat eskaini zuela. Egin beheko egiaztapenak ordenan eta gelditu lehen hutsegitean, hosts sarrera batek edo cachean gordetako erantzun batek geroagoko egiaztapen bakoitza arrazoi okerrengatik pasa dezakelako. Ordena hau VPN profiletatik ondoan daukadan testu-fitxategi batean gordetzen dut, konponketak ez baitu ezer aldatzen tunelari dagokionez eta dena aldatzen du bezeroak dakienari dagokionez.

Hasi bezeroak benetan jasotzen duen helbidearekin

Galdetu ebazleari zuzenean, aplikazioari fidatu beharrean. Windowsen, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net-k erakusten du zein ikuspegi jaso zuen bezeroak. Erantzun publiko batek esan nahi du beherago ezerk ez diola amaiera-puntuari helduko; amaiera-puntuaren helbide pribatuak esan nahi du DNS amaituta dagoela eta hurrengo egiaztapena konexioa bera dela.

Amaiera-puntu pribatu batek ez dio zerbitzuari izena aldatzen. Kontuak edo aplikazioak ohiko izen oso kualifikatua mantentzen du, eta amaiera-puntuak izen horrek sare birtualaren barruko bezeroentzat ebazten duen helbidea baino ez du aldatzen. Horregatik ostalari-izen berak modu pribatuan ebazten du sareko VM batetik eta modu publikoan inoiz ikuspegi pribatua jaso ez zuen eramangarri batetik.

Egiaztatu eremua, haren esteka eta erregistroa tunelaren aurretik

Hiru baldintza batera bete behar dira: eremu pribatua existitzen da, VPN atebidea eta bezeroak Azure-ra sartzen diren sare birtualera estekatuta dago, eta amaiera-puntuaren A erregistro bat dauka helbide pribatura seinalatzen duena. Estekatu eremua erlazionatutako ez den sare batera eta atebideak erregistro publikoa ebazten jarraituko du, tuneleko guztia osasuntsu ematen duen bitartean.

Eremu-izenak zerbitzuei dagozkie, ez orokorrean esteka pribatuei. App Service-k normalean privatelink.azurewebsites.net erabiltzen du, biltegiraketak eta SQLk beren izen-espazioak dituzte, eta beste zerbitzu baten eremua mailegatzeak existitzen den eta ezer erabilgarririk erantzuten ez duen eremu bat sortzen du.

Eman bezeroari benetan iristeko moduko ebazle bat

168.63.129.16-k Azure makineria birtualetatik erantzuten du eta ez da DNS zerbitzaria point-to-site tunelaren beste aldean dagoen eramangarri batentzat. Bezeroak tuneletik iristeko moduko ebazlea behar du: Azure DNS Private Resolverren sarrera-amaiera-puntua, sare birtualaren barruko birbidaltzailea, edo VPN bezeroaren profilean eramaten diren DNS zerbitzariaren sarrerak, bezeroak sare birtualari zuzenean galdetu dezan.

Konfiguratuta baina iristezina den ebazle batek ebazlerik ez bezala jokatzen du zehazki, eta sintoma denbora-muga da, ez erantzun okerra, horregatik suebaki arazo gisa irakurtzen da oker. Probatu tuneletik eraman behar duen kontsulta batekin, tokiko estekatik bestela ere arrakastatsua izango litzatekeen izen publiko batekin beharrean.

Konfigurazioak bultzatzen beharrean birbidaltzen baduzu, birbidali eremu pribatuaren jabe den izen-espazioa, privatelink.azurewebsites.net, azurewebsites.net osoaren ordez. Guraso-atzizki osoa iresten duen baldintzapeko birbidaltzaile batek zerbitzuaren bilaketa guztiak Azure-ra bidaltzen ditu, tokikoak izan beharko luketenak barne.

Erabili ziurtagiria eman zeneko izena

Helbidea zuzena denean, bigarren matxura agertzen da. Biltegiraketak eta App Service-k privatelink aliasa argitaratzen dute, eta alias hori ez da nahitaez ziurtagiriko izena. privatelink.blob.core.windows.net-ra zuzendutako AzCopy karga batek baliozkotzea huts egin zuen; <account>.blob.core.windows.net/<container>-rako karga berak helbide pribatura ebatzi eta pasa zuen, beraz bide pribatuan geratu zen gainidazketarik gabe.

Araua nabigatzailean eta App Service-rako ere balio du: konektatu ziurtagiriak estaltzen duen ostalari-izenarekin eta utzi DNSri helbide pribatua ematen. Ez joan baliozkotzea saihestera, izendapen-errore bat segurtasun-erregresio bihurtzen baitu. Ping arrakastatsu batek ibilbidea frogatzen du eta ezer ez dio esku-emanaren barruko izenari buruz, horregatik dira egiaztapen bereiziak.

Geruza bakoitza isolatzen duen lau urratseko ordena

1. Egiaztatu VPN bezeroak point-to-site multzoko helbide bat duela eta amaiera-puntuaren helbide pribaturako ibilbidea duela.
2. Ebatz ezazu aplikazioak erabiltzen duen izen zehatza eta alderatu erantzuna amaiera-puntuaren helbidearekin.
3. Ireki TCP konexio bat amaiera-puntuarekin zerbitzuaren atakan, eta gero irakurri konexio horretan aurkeztutako ziurtagiriaren izena.
4. Orain baino ez probatu baimena, bide erabilgarri batek eta ziurtagiri baliozkoa batek oraindik ez baitute baliabiderako sarbiderik ematen.

Helbidea zuzena denean ukatutako konexio batek sare-segurtasun taldea edo amaiera-puntu pribatuaren konexio-egoera seinalatzen ditu, ez DNSa, beraz egiaztatu horiek ebazlearen ezarpenak berriro editatu aurretik. TLS izen-desadostasun batek URLko ostalari-izenera eta ziurtagiriaren subject-era bidaltzen zaitu. Eduki batera ebazpen-irteera, ziurtagiriaren izena eta URL zehatza; hiru balio horiek azaltzen dituzte kasu hauetako gehienak atebidea ukitu gabe.

Erabili sare birtualaren barruko VM bat kontrol gisa. Izena han modu pribatuan eta tuneletik modu publikoan ebazten bada, eremua eta erregistroa zuzenak dira eta aldea bezeroaren ebazle-bidea baino ez da, amaiera-puntuaren konfigurazioan beste itzuli bat baino azkarrago egiaztatzen dena.

Bezeroek ere cachean gordetzen dute. Duela hamar minutu modu publikoan erantzun zuen erregistro batek erantzuten jarraitzen du eremua konpondu ondoren, beraz hustu cachea berriro probatu aurretik. Windowsen, ipconfig /flushdns-k bezeroaren cachea garbitzen du; izen-ebazpen politikaren arauek irauten dute, zein atzizki zein zerbitzarira doan erabakitzen dute, eta orain ordezkatu duzun ebazleari izen-espazioa bidaltzen jarrai dezakete.

Non dagokio hosts sarrera bati

Amaiera-puntuaren helbidea hosts fitxategi bati gehitzea diagnostiko ona da eta diseinu txarra. Izenaren eta helbidearen arteko mapaketa falta den pieza dela frogatzen du eta urrats horren ondorengo guztia probatzeko aukera ematen dizu, baina zure erabiltzaileentzat ikusezina da, amaiera-puntuaren helbidea aldatzen denean apurtzen da, eta erantzun beharko lukeen eremua ezkutatzen du.

Geratzen den proba-sarrera bat cache zaharkitu bat baino okerragoa da, errorearen norabidearen arabera konpondutako bidea apurtuta edo bide apurtua konponduta ager baitaiteke. Kendu ezazu azken itzulia baino lehen eta ebatz ezazu ekoizpen-ebazlearekin soilik.

Izen laburrek bilaketa-atzizki bat behar dute eta izen osoek ez, beraz probatu lehenengo izen osoa, eta gero erabaki lan-fluxuak bezeroaren profiletik bultzatutako atzizki bat behar duen. Microsoftek zerbitzu bakoitzeko eremu-izenak eta erregistro-formak dokumentatzen ditu bere amaiera-puntu pribatuen DNS jarraibideetan; irakurri zure zerbitzuaren sarrera, beste batetik eremu bat kopiatu beharrean.