Azure P2S VPN ei suuda privaatse lõpp-punkti nime lahendada

Ühendate point-to-site tunneliga, pingite privaatset aadressi, avate rakenduse ja saate hoopis 403 või sertifikaadivea. Mõlemad sümptomid viitavad DNS-ile, kuid need on erinevad rikked: üks tähendab, et klient lahendas avaliku aadressi, teine, et ta lahendas privaatse aadressi ja pakkus siis nime, mida sertifikaat ei kata. Käige allolevad kontrollid järjekorras läbi ja peatuge esimese tõrke juures, sest hosts-kirje või vahemällu salvestatud vastus võib panna iga hilisema kontrolli läbima vale põhjuse tõttu. Hoian seda järjekorda tekstifailis oma VPN-profiilide kõrval, sest parandus ei muuda tunnelis midagi ja muudab kõike selles, mida klient teab.

Alustage aadressist, mille klient tegelikult saab

Küsige resolverilt otse, selle asemel et rakendust usaldada. Windowsis näitab nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net, millise vaate klient sai. Avalik vastus tähendab, et midagi allavoolu ei jõua lõpp-punkti; lõpp-punkti privaatne aadress tähendab, et DNS on lõpetatud ja järgmine kontroll on ühendus ise.

Privaatne lõpp-punkt ei nimeta teenust ümber. Konto või rakendus säilitab oma tavapärase täielikult kvalifitseeritud nime ja lõpp-punkt muudab ainult seda aadressi, millele see nimi virtuaalvõrgu sees olevate klientide jaoks lahendatakse. Seetõttu lahendatakse sama hostinimi võrgus olevast VM-ist privaatselt ja sülearvutist, mis ei saanud kunagi privaatset vaadet, avalikult.

Kontrollige tsooni, selle linki ja kirjet enne tunnelit

Kolm tingimust peavad kehtima korraga: privaatne tsoon on olemas, see on lingitud virtuaalvõrguga, kuhu VPN-lüüs ja kliendid Azure'i sisenevad, ja see sisaldab lõpp-punkti A-kirjet, mis osutab privaatsele aadressile. Linkige tsoon mittekuuluvasse võrku ja lüüs jätkab avaliku kirje lahendamist, samal ajal kui tunnelis näib kõik terve olevat.

Tsooninimed kuuluvad teenustele, mitte üldiselt privaatsetele linkidele. App Service kasutab tavaliselt privatelink.azurewebsites.net, salvestusel ja SQL-il on oma nimeruumid, ning teise teenuse tsooni laenamine loob tsooni, mis on olemas ega vasta midagi kasulikku.

Andke kliendile resolver, millele ta tegelikult ligi pääseb

168.63.129.16 vastab Azure'i virtuaalmasinatest ega ole DNS-server point-to-site tunneli teisel poolel olevale sülearvutile. Klient vajab tunnelist kättesaadavat resolverit: Azure DNS Private Resolveri sissetulev lõpp-punkt, virtuaalvõrgu sisene edastaja või VPN-kliendi profiilis kantavad DNS-serveri kirjed, et klient küsiks virtuaalvõrku otse.

Seadistatud, kuid kättesaamatu resolver käitub täpselt nagu resolveri puudumine ja sümptomiks on aegumine, mitte vale vastus, mistõttu loetakse seda ekslikult tulemüüriprobleemiks. Testige seda päringuga, mida tunnel peab kandma, mitte avaliku nimega, mis oleks kohaliku lingi kaudu niikuinii õnnestunud.

Kui edastate selle asemel, et seadeid peale suruda, edastage nimeruum, millele privaatne tsoon kuulub, privatelink.azurewebsites.net, mitte kogu azurewebsites.net. Tingimuslik edastaja, mis neelab kogu ülemkataloogi järelliite, saadab Azure'i iga teenuse otsingu, sealhulgas need, mis peaksid jääma kohalikuks.

Kasutage nime, mille jaoks sertifikaat väljastati

Kui aadress on õige, tuleb välja teine rike. Salvestus ja App Service avaldavad privatelink varjunime ja see varjunimi ei pruugi olla sertifikaadis olev nimi. AzCopy üleslaadimine aadressile privatelink.blob.core.windows.net ei läbinud valideerimist; sama üleslaadimine aadressile <account>.blob.core.windows.net/<container> lahendati privaatsele aadressile ja läbis, nii et see jäi privaatsele teele ilma möödasõiduta.

Reegel kehtib brauseris ja ka App Service'i puhul: ühenduge hostinimega, mida sertifikaat katab, ja laske DNS-il pakkuda privaatne aadress. Ärge kasutage valideerimise möödasõitu, sest see muudab nimevea turvaregressiooniks. Õnnestunud ping tõestab marsruuti ega ütle midagi nime kohta käepigistuse sees, mistõttu need jäävad eraldi kontrollideks.

Nelja sammu järjekord, mis isoleerib iga kihi

1. Kinnitage, et VPN-kliendil on point-to-site'i basseinist saadud aadress ja marsruut lõpp-punkti privaatsele aadressile.
2. Lahendage täpne nimi, mida rakendus kasutab, ja võrrelge vastust lõpp-punkti aadressiga.
3. Avage TCP-ühendus lõpp-punktiga teenuse pordil ja lugege seejärel sellel ühendusel esitatud sertifikaadi nimi.
4. Alles nüüd testige autoriseerimist, sest töötav tee ja kehtiv sertifikaat ei anna veel ressursile juurdepääsu.

Tagasi lükatud ühendus õige aadressi juures viitab võrgu turvagrupile või privaatse lõpp-punkti ühenduse olekule, mitte DNS-ile, seega kontrollige neid enne, kui resolveri seadeid uuesti muudate. TLS-i nime lahknevus saadab teid tagasi URL-is oleva hostinime ja sertifikaadi subject'i juurde. Hoidke lahendustulemus, sertifikaadi nimi ja täpne URL koos; need kolm väärtust selgitavad enamikku neist juhtudest ilma lüüsi puutumata.

Kasutage kontrollina virtuaalvõrgus olevat VM-i. Kui nimi lahendatakse seal privaatselt ja tunnelist avalikult, on tsoon ja kirje õiged ning ainus erinevus on kliendi resolveri tee, mida on kiirem kinnitada kui veel üks ring lõpp-punkti konfiguratsioonist.

Kliendid vahemällu salvestavad ka. Kirje, mis vastas avalikult kümme minutit tagasi, vastab edasi ka pärast tsooni parandamist, seega tühjendage vahemälu enne uuesti testimist. Windowsis puhastab ipconfig /flushdns kliendi vahemälu; nimelahenduse poliitika reeglid jäävad alles, otsustavad, milline järelliide millisesse serverisse läheb, ja võivad saata nimeruumi edasi resolverile, mille te just asendasite.

Kuhu hosts-kirje kuulub

Lõpp-punkti aadressi lisamine hosts-faili on hea diagnostika ja halb disain. See tõestab, et puudu on just nime ja aadressi vastavus, ning laseb testida kõike pärast seda sammu, kuid see on teie kasutajatele nähtamatu, läheb katki, kui lõpp-punkti aadress muutub, ja peidab tsooni, mis peaks vastama.

Alles jäänud testkirje on hullem kui aegunud vahemälu, sest see võib panna parandatud tee katkise või katkise tee parandatud välja nägema, olenevalt vea suunast. Eemaldage see enne viimast ringi ja lahendage ainult tootmisresolveriga.

Lühikesed nimed vajavad otsingujärelliidet ja täielikult kvalifitseeritud nimed mitte, seega testige esmalt täielikult kvalifitseeritud nime ja otsustage siis, kas töövoog vajab kliendiprofiili kaudu peale surutavat järelliidet. Microsoft dokumenteerib tsooninimed ja kirjete vormid teenuste kaupa oma privaatsete lõpp-punktide DNS-juhistes; lugege oma teenuse kirjet, selle asemel et kopeerida tsooni teisest.