Azure P2S VPN kan ikke slå et privat endpoint-navn op

Du opretter point-to-site-tunnelen, pinger den private adresse, åbner appen og får i stedet en 403 eller en certifikatfejl. Begge symptomer peger på DNS, men de er forskellige fejl: den ene betyder, at klienten har slået den offentlige adresse op, den anden at den slog den private adresse op og derefter tilbød et navn, som certifikatet ikke dækker. Gå kontrollerne nedenfor igennem i rækkefølge, og stop ved den første fejl, fordi en hosts-post eller et cachet svar kan få hver senere kontrol til at bestå af den forkerte grund. Jeg har denne rækkefølge i en tekstfil ved siden af mine VPN-profiler, fordi rettelsen ikke ændrer noget ved tunnelen og alt ved, hvad klienten ved.

Begynd med den adresse, klienten faktisk får

Spørg resolveren direkte i stedet for at stole på applikationen. På Windows viser nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net, hvilket view klienten fik. Et offentligt svar betyder, at intet længere fremme når endpointet; endpointets private adresse betyder, at DNS er færdigt, og at den næste kontrol er selve forbindelsen.

Et privat endpoint omdøber ikke tjenesten. Kontoen eller appen beholder sit sædvanlige fuldt kvalificerede navn, og endpointet ændrer kun den adresse, som navnet slås op til for klienter inde i det virtuelle netværk. Derfor slås det samme værtsnavn op privat fra en VM i netværket og offentligt fra en bærbar, som aldrig fik det private view.

Kontroller zonen, dens link og posten før tunnelen

Tre betingelser skal være opfyldt samtidig: den private zone findes, den er linket til det virtuelle netværk, hvor VPN-gatewayen og klienterne går ind i Azure, og den indeholder en A-post for endpointet, der peger på den private adresse. Linker du zonen til et uvedkommende netværk, bliver gatewayen ved med at slå den offentlige post op, mens alt ved tunnelen stadig ser sundt ud.

Zonenavne tilhører tjenester, ikke private links generelt. App Service bruger normalt privatelink.azurewebsites.net, lager og SQL har deres egne navnerum, og at låne en anden tjenestes zone giver en zone, der findes og ikke svarer noget brugbart.

Giv klienten en resolver, den faktisk kan nå

168.63.129.16 svarer fra Azure-virtuelle maskiner og er ikke en DNS-server for en bærbar på den anden side af en point-to-site-tunnel. Klienten har brug for en resolver, der kan nås gennem tunnelen: et indgående endpoint i Azure DNS Private Resolver, en videresender inde i det virtuelle netværk eller DNS-serverposter, der bæres i VPN-klientprofilen, så klienten spørger det virtuelle netværk direkte.

En konfigureret, men utilgængelig resolver opfører sig præcis som ingen resolver, og symptomet er en timeout frem for et forkert svar, og derfor læses det som et firewallproblem. Test den med en forespørgsel, som tunnelen skal bære, ikke med et offentligt navn, der alligevel ville lykkes over det lokale link.

Hvis du videresender i stedet for at skubbe indstillinger, så videresend det navnerum, som den private zone ejer, privatelink.azurewebsites.net frem for hele azurewebsites.net. En betinget videresender, der sluger hele det overordnede suffiks, sender hvert opslag for tjenesten til Azure, også dem der burde blive lokale.

Brug det navn, certifikatet blev udstedt til

Når adressen er rigtig, dukker den anden fejl op. Lager og App Service udgiver et privatelink-alias, og det alias er ikke nødvendigvis navnet i certifikatet. En AzCopy-upload rettet mod privatelink.blob.core.windows.net bestod ikke valideringen; den samme upload til <account>.blob.core.windows.net/<container> blev slået op til den private adresse og bestod, så den blev på den private vej uden en tilsidesættelse.

Reglen gælder i en browser og også for App Service: forbind med det værtsnavn, certifikatet dækker, og lad DNS levere den private adresse. Grib ikke efter en valideringsomgåelse, for den gør en navnefejl til en sikkerhedsregression. En vellykket ping beviser ruten og siger intet om navnet inde i håndtrykket, og derfor bliver de ved med at være adskilte kontroller.

En rækkefølge på fire trin, der isolerer hvert lag

1. Bekræft, at VPN-klienten har en adresse fra point-to-site-puljen og en rute til endpointets private adresse.
2. Slå det præcise navn op, som applikationen bruger, og sammenlign svaret med endpointets adresse.
3. Åbn en TCP-forbindelse til endpointet på tjenestens port, og læs derefter certifikatnavnet, der præsenteres på den forbindelse.
4. Test først nu autorisation, fordi en fungerende vej og et gyldigt certifikat stadig ikke giver adgang til ressourcen.

En afvist forbindelse, mens adressen er korrekt, peger på netværkssikkerhedsgruppen eller den private endpoint-forbindelses tilstand, ikke på DNS, så kontroller dem, før du redigerer resolverindstillinger igen. En TLS-navnemismatch sender dig tilbage til værtsnavnet i URL'en og certifikatets subject. Hold opløsningsoutput, certifikatnavn og den præcise URL sammen; de tre værdier forklarer de fleste af disse sager uden at røre gatewayen.

Brug en VM inde i det virtuelle netværk som kontrol. Hvis navnet slås op privat der og offentligt fra tunnelen, er zonen og posten korrekte, og den eneste forskel er klientens resolvervej, som er hurtigere at bekræfte end endnu en gennemgang af endpoint-konfigurationen.

Klienter cacher også. En post, der svarede offentligt for ti minutter siden, bliver ved med at svare, efter du har rettet zonen, så tøm cachen, før du tester igen. På Windows rydder ipconfig /flushdns klientcachen; regler for navneopløsningspolitik består, bestemmer hvilket suffiks der går til hvilken server og kan blive ved med at sende navnerummet til den resolver, du netop har erstattet.

Hvor en hosts-post hører hjemme

At tilføje endpointets adresse til en hosts-fil er god diagnostik og dårligt design. Det beviser, at navn-til-adresse-mappingen er den manglende brik, og lader dig teste alt efter det trin, men det er usynligt for dine brugere, går i stykker, når endpointets adresse ændres, og skjuler den zone, der burde svare.

En efterladt testpost er værre end en forældet cache, fordi den kan få den rettede vej til at se brudt ud eller den brudte vej til at se rettet ud afhængigt af fejlens retning. Fjern den før den sidste gennemkørsel, og slå kun op med produktionsresolveren.

Korte navne kræver et søgesuffiks, og fuldt kvalificerede navne gør ikke, så test det fuldt kvalificerede navn først, og beslut derefter, om arbejdsgangen har brug for et suffiks, der skubbes gennem klientprofilen. Microsoft dokumenterer zone-navnene og postformerne pr. tjeneste i sine DNS-retningslinjer for private endpoints; læs posten for din tjeneste i stedet for at kopiere en zone fra en anden.