Azure P2S VPN ne povas solvi nomon de privata finpunkto

Vi konektas la tunelon point-to-site, pingas la privatan adreson, malfermas la aplikaĵon kaj anstataŭe ricevas 403 aŭ atestilan eraron. Ambaŭ simptomoj montras al DNS, sed ili estas malsamaj difektoj: unu signifas, ke la kliento solvis la publikan adreson, la alia, ke ĝi solvis la privatan adreson kaj poste proponis nomon, kiun la atestilo ne kovras. Trapasu la subajn kontrolojn laŭ ordo kaj haltu ĉe la unua malsukceso, ĉar hosts-rikordo aŭ kaŝita respondo povas igi ĉiun postan kontrolon sukcesi pro la malĝusta kialo. Mi tenas ĉi tiun ordon en tekstdosiero apud miaj VPN-profiloj, ĉar la riparo ŝanĝas nenion pri la tunelo kaj ĉion pri tio, kion la kliento scias.

Komencu per la adreso, kiun la kliento efektive ricevas

Demandu la solvilon rekte anstataŭ fidi la aplikaĵon. En Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net montras, kiun vidon la kliento ricevis. Publika respondo signifas, ke nenio pli malsupre atingos la finpunkton; la privata adreso de la finpunkto signifas, ke DNS finiĝis kaj la sekva kontrolo estas la konekto mem.

Privata finpunkto ne renomigas la servon. La konto aŭ aplikaĵo konservas sian kutiman plene kvalifikitan nomon, kaj la finpunkto ŝanĝas nur la adreson, al kiu tiu nomo solviĝas por klientoj ene de la virtuala reto. Tial la sama hostonomo solviĝas private el VM en la reto kaj publike el tekkomputilo, kiu neniam ricevis la privatan vidon.

Kontrolu la zonon, ĝian ligon kaj la rikordon antaŭ la tunelo

Tri kondiĉoj devas validi kune: la privata zono ekzistas, ĝi estas ligita al la virtuala reto, en kiun la VPN-pordego kaj la klientoj eniras Azure, kaj ĝi enhavas A-rikordon por la finpunkto montrantan al la privata adreso. Ligigu la zonon al nerilata reto kaj la pordego daŭre solvos la publikan rikordon, dum ĉio pri la tunelo ankoraŭ aspektas sana.

Zonnomoj apartenas al servoj, ne ĝenerale al privataj ligoj. App Service kutime uzas privatelink.azurewebsites.net, stokado kaj SQL havas siajn proprajn nomspacojn, kaj prunti zonon de alia servo produktas zonon, kiu ekzistas kaj respondas nenion utilan.

Donu al la kliento solvilon, kiun ĝi vere povas atingi

168.63.129.16 respondas el Azure-virtualaj maŝinoj kaj ne estas DNS-servilo por tekkomputilo aliflanke de point-to-site-tunelo. La kliento bezonas solvilon atingeblan tra la tunelo: envenan finpunkton de Azure DNS Private Resolver, plusendilon ene de la virtuala reto, aŭ DNS-servilajn rikordojn portatajn en la VPN-klienta profilo, por ke la kliento demandu la virtualan reton rekte.

Agordita sed neatingebla solvilo kondutas precize kiel neniu solvilo, kaj la simptomo estas tempolimo anstataŭ malĝusta respondo, tial ĝi estas mislegata kiel fajroŝirma problemo. Testu ĝin per demando, kiun la tunelo devas porti, ne per publika nomo, kiu sukcesus per la loka ligo ĉiuokaze.

Se vi plusendas anstataŭ puŝi agordojn, plusendu la nomspacon, kiun posedas la privata zono, privatelink.azurewebsites.net anstataŭ la tuta azurewebsites.net. Kondiĉa plusendilo, kiu glutas la tutan gepatran sufikson, sendas ĉiun serĉon por la servo al Azure, inkluzive de tiuj, kiuj devus resti lokaj.

Uzu la nomon, por kiu la atestilo estis eldonita

Kiam la adreso estas ĝusta, montriĝas la dua difekto. Stokado kaj App Service publikigas kromnomon privatelink, kaj tiu kromnomo ne nepre estas la nomo en la atestilo. AzCopy-alŝuto adresita al privatelink.blob.core.windows.net malsukcesis la validigon; la sama alŝuto al <account>.blob.core.windows.net/<container> solviĝis al la privata adreso kaj sukcesis, do ĝi restis sur la privata vojo sen superregado.

La regulo validas en retumilo kaj ankaŭ por App Service: konektu per la hostonomo, kiun la atestilo kovras, kaj lasu DNS provizi la privatan adreson. Ne prenu validigajn preterpasejojn, ĉar ili igas nomeraron sekurecan regreson. Sukcesa ping pruvas la vojon kaj diras nenion pri la nomo ene de la manpremo, tial ĉi tiuj restas apartaj kontroloj.

Ordo de kvar paŝoj, kiu izolas ĉiun tavolon

1. Konfirmu, ke la VPN-kliento havas adreson el la point-to-site-baseno kaj vojon al la privata adreso de la finpunkto.
2. Solvu la precizan nomon, kiun la aplikaĵo uzas, kaj komparu la respondon kun la adreso de la finpunkto.
3. Malfermu TCP-konekton al la finpunkto sur la serva pordo, poste legu la atestilan nomon prezentatan sur tiu konekto.
4. Nur nun testu rajtigon, ĉar funkcianta vojo kaj valida atestilo ankoraŭ ne donas aliron al la rimedo.

Rifuzita konekto dum la adreso estas ĝusta montras al la reta sekureca grupo aŭ al la stato de la privata finpunkta konekto, ne al DNS, do kontrolu tiujn antaŭ ol denove redakti la solvilajn agordojn. TLS-nommalakordo resendas vin al la hostonomo en la URL kaj al la subject de la atestilo. Tenu kune la solvan eligon, la atestilan nomon kaj la precizan URL; tiuj tri valoroj klarigas la plej multajn el tiuj kazoj sen tuŝi la pordegon.

Uzu VM ene de la virtuala reto kiel kontrolon. Se la nomo solviĝas tie private kaj publike el la tunelo, la zono kaj la rikordo estas ĝustaj kaj la sola diferenco estas la solvila vojo de la kliento, kio konfirmiĝas pli rapide ol alia trairo de la finpunkta agordo.

Klientoj ankaŭ kaŝmemorigas. Rikordo, kiu respondis publike antaŭ dek minutoj, daŭre respondas post kiam vi riparis la zonon, do malplenigu la kaŝmemoron antaŭ ol retesti. En Windows, ipconfig /flushdns malplenigas la klientan kaŝmemoron; reguloj de nom-solva politiko restas, decidas kiun sufikson iras al kiu servilo, kaj povas daŭre sendi la nomspacon al la solvilo, kiun vi ĵus anstataŭigis.

Kie apartenas hosts-rikordo

Aldoni la adreson de la finpunkto al hosts-dosiero estas bona diagnozo kaj malbona dezajno. Ĝi pruvas, ke la nom-al-adresa mapado estas la mankanta peco, kaj lasas vin testi ĉion post tiu paŝo, sed ĝi estas nevidebla por viaj uzantoj, rompiĝas kiam la adreso de la finpunkto ŝanĝiĝas, kaj kaŝas la zonon, kiu devus respondi.

Restinta testa rikordo estas pli malbona ol kaduka kaŝmemoro, ĉar ĝi povas igi la riparitan vojon aspekti rompita aŭ la rompitan vojon aspekti riparita, depende de la direkto de la eraro. Forigu ĝin antaŭ la fina trairo kaj solvu nur per la produkta solvilo.

Mallongaj nomoj bezonas serĉan sufikson kaj plene kvalifikitaj ne, do testu unue la plene kvalifikitan nomon, poste decidu, ĉu la laborfluo bezonas sufikson puŝatan tra la klienta profilo. Microsoft dokumentas la zonnomojn kaj rikordformojn por ĉiu servo en siaj gvidlinioj pri DNS por privataj finpunktoj; legu la rikordon por via servo anstataŭ kopii zonon de alia.