Azure P2S VPN nu poate rezolva numele unui punct final privat

Vă conectați la tunelul point-to-site, faceți ping la adresa privată, deschideți aplicația și primiți în schimb un 403 sau o eroare de certificat. Ambele simptome indică DNS, dar sunt defecțiuni diferite: unul înseamnă că clientul a rezolvat adresa publică, celălalt că a rezolvat adresa privată și apoi a oferit un nume pe care certificatul nu îl acoperă. Parcurgeți verificările de mai jos în ordine și opriți-vă la prima defecțiune, pentru că o intrare hosts sau un răspuns din cache pot face ca fiecare verificare ulterioară să treacă din motivul greșit. Țin această ordine într-un fișier text lângă profilurile mele VPN, pentru că remedierea nu schimbă nimic la tunel și schimbă totul în ce știe clientul.

Începeți cu adresa pe care clientul o primește efectiv

Întrebați resolverul direct, în loc să aveți încredere în aplicație. În Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net arată ce vedere a primit clientul. Un răspuns public înseamnă că nimic mai departe nu va ajunge la punctul final; adresa privată a punctului final înseamnă că DNS s-a terminat și că următoarea verificare este conexiunea în sine.

Un punct final privat nu redenumește serviciul. Contul sau aplicația își păstrează numele complet obișnuit, iar punctul final schimbă doar adresa către care acel nume se rezolvă pentru clienții din rețeaua virtuală. De aceea același nume de gazdă se rezolvă privat de pe o VM din rețea și public de pe un laptop care nu a primit niciodată vederea privată.

Verificați zona, legătura ei și înregistrarea înainte de tunel

Trei condiții trebuie să fie valabile împreună: zona privată există, este legată de rețeaua virtuală în care intră în Azure gateway-ul VPN și clienții, și conține o înregistrare A pentru punctul final care indică adresa privată. Legați zona de o rețea fără legătură și gateway-ul va continua să rezolve înregistrarea publică în timp ce totul la tunel pare sănătos.

Numele zonelor aparțin serviciilor, nu legăturilor private în general. App Service folosește de obicei privatelink.azurewebsites.net, stocarea și SQL au propriile spații de nume, iar împrumutarea zonei altui serviciu produce o zonă care există și nu răspunde nimic util.

Dați clientului un resolver pe care chiar îl poate atinge

168.63.129.16 răspunde din mașini virtuale Azure și nu este un server DNS pentru un laptop de cealaltă parte a unui tunel point-to-site. Clientul are nevoie de un resolver accesibil prin tunel: un punct final de intrare al Azure DNS Private Resolver, un redirector din rețeaua virtuală, sau intrări de server DNS purtate în profilul clientului VPN pentru ca clientul să întrebe direct rețeaua virtuală.

Un resolver configurat, dar inaccesibil se comportă exact ca niciun resolver, iar simptomul este un timeout și nu un răspuns greșit, motiv pentru care este citit greșit ca problemă de firewall. Testați-l cu o interogare pe care tunelul ar trebui să o transporte, nu cu un nume public care ar fi reușit oricum prin legătura locală.

Dacă redirecționați în loc să împingeți setări, redirecționați spațiul de nume pe care îl deține zona privată, privatelink.azurewebsites.net în loc de tot azurewebsites.net. Un redirector condiționat care înghite întregul sufix părinte trimite la Azure fiecare căutare a serviciului, inclusiv pe cele care ar trebui să rămână locale.

Folosiți numele pentru care a fost emis certificatul

Când adresa este corectă, apare a doua defecțiune. Stocarea și App Service publică un alias privatelink, iar acel alias nu este neapărat numele din certificat. Un upload AzCopy adresat către privatelink.blob.core.windows.net a eșuat validarea; același upload către <account>.blob.core.windows.net/<container> s-a rezolvat la adresa privată și a trecut, așa că a rămas pe calea privată fără nicio ocolire.

Regula este valabilă în browser și și pentru App Service: conectați-vă cu numele de gazdă pe care certificatul îl acoperă și lăsați DNS să furnizeze adresa privată. Nu recurgeți la ocolirea validării, pentru că transformă o greșeală de denumire într-o regresie de securitate. Un ping reușit dovedește ruta și nu spune nimic despre numele din interiorul strângerii de mână, de aceea acestea rămân verificări separate.

O ordine de patru pași care izolează fiecare strat

1. Confirmați că clientul VPN are o adresă din pool-ul point-to-site și o rută către adresa privată a punctului final.
2. Rezolvați numele exact pe care îl folosește aplicația și comparați răspunsul cu adresa punctului final.
3. Deschideți o conexiune TCP către punctul final pe portul serviciului, apoi citiți numele certificatului prezentat pe acea conexiune.
4. Abia acum testați autorizarea, pentru că o cale funcțională și un certificat valid încă nu dau acces la resursă.

O conexiune refuzată în timp ce adresa este corectă indică grupul de securitate al rețelei sau starea conexiunii punctului final privat, nu DNS, așa că verificați-le înainte de a modifica din nou setările resolverului. O nepotrivire de nume TLS vă trimite înapoi la numele de gazdă din URL și la subjectul certificatului. Țineți împreună ieșirea rezolvării, numele certificatului și URL-ul exact; aceste trei valori explică majoritatea acestor cazuri fără a atinge gateway-ul.

Folosiți o VM din rețeaua virtuală ca martor. Dacă numele se rezolvă privat acolo și public din tunel, zona și înregistrarea sunt corecte și singura diferență este calea resolverului clientului, care se confirmă mai repede decât încă o trecere prin configurația punctului final.

Clienții memorează și ei. O înregistrare care a răspuns public acum zece minute continuă să răspundă după ce ați corectat zona, așa că goliți cache-ul înainte de a retesta. În Windows, ipconfig /flushdns curăță cache-ul clientului; regulile de politică pentru rezolvarea numelor persistă, decid ce sufix merge la ce server și pot continua să trimită spațiul de nume către resolverul pe care tocmai l-ați înlocuit.

Unde îi este locul unei intrări hosts

Adăugarea adresei punctului final într-un fișier hosts este o diagnoză bună și un design prost. Dovedește că maparea nume-la-adresă este piesa lipsă și vă lasă să testați tot ce urmează, dar este invizibilă pentru utilizatorii voștri, se strică atunci când se schimbă adresa punctului final și ascunde zona care ar trebui să răspundă.

O intrare de test rămasă este mai rea decât un cache învechit, pentru că poate face calea reparată să pară stricată sau calea stricată să pară reparată, în funcție de direcția erorii. Eliminați-o înainte de trecerea finală și rezolvați doar cu resolverul de producție.

Numele scurte au nevoie de un sufix de căutare, iar numele complete nu, așa că testați mai întâi numele complet și apoi decideți dacă fluxul de lucru are nevoie de un sufix împins prin profilul clientului. Microsoft documentează numele zonelor și formele înregistrărilor pentru fiecare serviciu în îndrumările DNS pentru puncte finale private; citiți intrarea pentru serviciul dvs. în loc să copiați o zonă de la altul.