Azure P2S VPN ne more razrešiti imena zasebne končne točke

Povežete predor point-to-site, pingate zasebni naslov, odprete aplikacijo in namesto tega dobite 403 ali napako potrdila. Oba simptoma kažeta na DNS, a gre za različni okvari: ena pomeni, da je odjemalec razrešil javni naslov, druga, da je razrešil zasebni naslov in nato ponudil ime, ki ga potrdilo ne pokriva. Pojdite skozi spodnja preverjanja po vrsti in se ustavite pri prvi napaki, ker lahko vnos v hosts ali odgovor iz predpomnilnika povzroči, da vsako nadaljnje preverjanje uspe iz napačnega razloga. Ta vrstni red hranim v besedilni datoteki ob svojih profilah VPN, ker popravek ne spremeni ničesar v predoru in vse v tem, kar ve odjemalec.

Začnite z naslovom, ki ga odjemalec dejansko dobi

Vprašajte razreševalnik neposredno, namesto da zaupate aplikaciji. V Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net pokaže, kateri pogled je prejel odjemalec. Javen odgovor pomeni, da nič dlje ne bo doseglo končne točke; zasebni naslov končne točke pomeni, da je DNS končan in da je naslednje preverjanje sama povezava.

Zasebna končna točka ne preimenuje storitve. Račun ali aplikacija ohrani svoje običajno polno kvalificirano ime, končna točka pa spremeni le naslov, na katerega se to ime razreši za odjemalce v virtualnem omrežju. Zato se isto ime gostitelja razreši zasebno z VM v omrežju in javno s prenosnika, ki nikoli ni dobil zasebnega pogleda.

Preverite območje, njegovo povezavo in zapis pred predorom

Trije pogoji morajo veljati hkrati: zasebno območje obstaja, povezano je z virtualnim omrežjem, v katero vstopata v Azure prehod VPN in odjemalci, in vsebuje zapis A za končno točko, ki kaže na zasebni naslov. Povežite območje z nepovezanim omrežjem in prehod bo še naprej razreševal javni zapis, medtem ko bo vse v predoru videti zdravo.

Imena območij pripadajo storitvam, ne zasebnim povezavam na splošno. App Service običajno uporablja privatelink.azurewebsites.net, shramba in SQL imata svoja imenska prostora, izposoja območja druge storitve pa ustvari območje, ki obstaja in ne odgovori nič koristnega.

Dajte odjemalcu razreševalnik, ki ga res lahko doseže

168.63.129.16 odgovarja z virtualnih strojev Azure in ni strežnik DNS za prenosnik na drugi strani predora point-to-site. Odjemalec potrebuje razreševalnik, dosegljiv skozi predor: vhodno končno točko Azure DNS Private Resolver, posredovalnik znotraj virtualnega omrežja ali vnose strežnika DNS, prenesene v profilu odjemalca VPN, da odjemalec vpraša virtualno omrežje neposredno.

Konfiguriran, a nedosegljiv razreševalnik se obnaša natanko kot noben razreševalnik, simptom pa je potek časa, ne napačen odgovor, zato se napačno bere kot težava požarnega zidu. Preizkusite ga s poizvedbo, ki jo mora predor prenašati, ne z javnim imenom, ki bi uspelo prek lokalne povezave tako ali tako.

Če posredujete, namesto da bi potiskali nastavitve, posredujte imenski prostor, ki ga ima zasebno območje, privatelink.azurewebsites.net, ne celotnega azurewebsites.net. Pogojni posredovalnik, ki pogoltne celotno nadrejeno pripono, pošlje v Azure vsako iskanje storitve, tudi tista, ki bi morala ostati lokalna.

Uporabite ime, za katero je bilo potrdilo izdano

Ko je naslov pravilen, se pokaže druga okvara. Shramba in App Service objavita vzdevek privatelink, ta vzdevek pa ni nujno ime v potrdilu. Nalaganje z AzCopy na privatelink.blob.core.windows.net ni prestalo preverjanja; isto nalaganje na <account>.blob.core.windows.net/<container> se je razrešilo na zasebni naslov in prestalo, zato je ostalo na zasebni poti brez obhoda.

Pravilo velja v brskalniku in za App Service: povežite se z imenom gostitelja, ki ga potrdilo pokriva, in pustite DNS, da zagotovi zasebni naslov. Ne zatekajte se k obhodu preverjanja, ker spremeni napako v poimenovanju v varnostno regresijo. Uspešen ping dokaže pot in ne pove nič o imenu znotraj rokovanja, zato to ostajajo ločena preverjanja.

Vrstni red štirih korakov, ki izolira vsak sloj

1. Potrdite, da ima odjemalec VPN naslov iz bazena point-to-site in pot do zasebnega naslova končne točke.
2. Razrešite točno ime, ki ga uporablja aplikacija, in primerjajte odgovor z naslovom končne točke.
3. Odprite povezavo TCP do končne točke na vratih storitve in nato preberite ime potrdila, predstavljeno na tej povezavi.
4. Šele zdaj preizkusite avtorizacijo, ker delujoča pot in veljavno potrdilo še ne dajeta dostopa do vira.

Zavrnjena povezava pri pravilnem naslovu kaže na varnostno skupino omrežja ali stanje povezave zasebne končne točke, ne na DNS, zato to preverite, preden znova urejate nastavitve razreševalnika. Neujemanje imena TLS vas vrne k imenu gostitelja v URL in k subjectu potrdila. Hranite skupaj izpis razrešitve, ime potrdila in točen URL; te tri vrednosti pojasnijo večino takih primerov, ne da bi se dotaknili prehoda.

Uporabite VM v virtualnem omrežju kot kontrolo. Če se ime tam razreši zasebno in iz predora javno, sta območje in zapis pravilna, edina razlika pa je pot razreševalnika odjemalca, kar se potrdi hitreje kot še en prehod skozi konfiguracijo končne točke.

Odjemalci tudi predpomnijo. Zapis, ki je pred desetimi minutami odgovoril javno, odgovarja še naprej tudi po popravku območja, zato pred ponovnim preizkusom izpraznite predpomnilnik. V Windows ipconfig /flushdns počisti predpomnilnik odjemalca; pravila politike razreševanja imen ostanejo, določajo, katera pripona gre na kateri strežnik, in lahko še naprej pošiljajo imenski prostor razreševalniku, ki ste ga pravkar zamenjali.

Kam spada vnos v hosts

Dodajanje naslova končne točke v datoteko hosts je dobra diagnostika in slab dizajn. Dokaže, da je preslikava imena v naslov manjkajoči del, in vam omogoči, da preizkusite vse po tem koraku, vendar je nevidno za vaše uporabnike, se pokvari, ko se naslov končne točke spremeni, in skrije območje, ki bi moralo odgovarjati.

Preostali preskusni vnos je slabši od zastarelega predpomnilnika, ker lahko glede na smer napake pokaže popravljeno pot kot zlomljeno ali zlomljeno pot kot popravljeno. Odstranite ga pred zadnjim prehodom in razrešujte samo s produkcijskim razreševalnikom.

Kratka imena potrebujejo iskalno pripono, polno kvalificirana pa ne, zato najprej preizkusite polno kvalificirano ime, nato pa se odločite, ali delovni tok potrebuje pripono, potisnjeno skozi profil odjemalca. Microsoft dokumentira imena območij in oblike zapisov za vsako storitev v svojih smernicah za DNS zasebnih končnih točk; preberite vnos za svojo storitev, namesto da kopirate območje iz druge.