Azure P2S VPN kan ikke slå opp navnet til et privat endepunkt

Du kobler til point-to-site-tunnelen, pinger den private adressen, åpner appen og får i stedet en 403 eller en sertifikatfeil. Begge symptomene peker på DNS, men de er forskjellige feil: den ene betyr at klienten slo opp den offentlige adressen, den andre at den slo opp den private adressen og deretter tilbød et navn sertifikatet ikke dekker. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved første feil, fordi en hosts-oppføring eller et bufret svar kan få hver senere kontroll til å bestå av feil grunn. Jeg har denne rekkefølgen i en tekstfil ved siden av VPN-profilene mine, fordi rettelsen ikke endrer noe ved tunnelen og alt ved det klienten vet.

Begynn med adressen klienten faktisk får

Spør resolveren direkte i stedet for å stole på applikasjonen. På Windows viser nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net hvilken visning klienten fikk. Et offentlig svar betyr at ingenting lenger ned når endepunktet; endepunktets private adresse betyr at DNS er ferdig og at neste kontroll er selve forbindelsen.

Et privat endepunkt gir ikke tjenesten nytt navn. Kontoen eller appen beholder sitt vanlige fullt kvalifiserte navn, og endepunktet endrer bare adressen navnet slås opp til for klienter inne i det virtuelle nettverket. Derfor slås samme vertsnavn opp privat fra en VM i nettverket og offentlig fra en bærbar maskin som aldri fikk den private visningen.

Kontroller sonen, koblingen og posten før tunnelen

Tre vilkår må gjelde samtidig: den private sonen finnes, den er koblet til det virtuelle nettverket der VPN-gatewayen og klientene går inn i Azure, og den inneholder en A-post for endepunktet som peker på den private adressen. Kobler du sonen til et uvedkommende nettverk, fortsetter gatewayen å slå opp den offentlige posten mens alt ved tunnelen ser friskt ut.

Sonenavn tilhører tjenester, ikke private koblinger generelt. App Service bruker vanligvis privatelink.azurewebsites.net, lagring og SQL har egne navnerom, og å låne en annen tjenestes sone gir en sone som finnes og ikke svarer noe nyttig.

Gi klienten en resolver den faktisk kan nå

168.63.129.16 svarer fra virtuelle Azure-maskiner og er ikke en DNS-server for en bærbar maskin på den andre siden av en point-to-site-tunnel. Klienten trenger en resolver som er tilgjengelig gjennom tunnelen: et innkommende endepunkt i Azure DNS Private Resolver, en videresender inne i det virtuelle nettverket, eller DNS-serveroppføringer som bæres i VPN-klientprofilen slik at klienten spør det virtuelle nettverket direkte.

En konfigurert, men utilgjengelig resolver oppfører seg akkurat som ingen resolver, og symptomet er tidsavbrudd i stedet for et feil svar, og derfor leses det som et brannmurproblem. Test den med en spørring tunnelen skal bære, ikke med et offentlig navn som uansett ville lykkes over den lokale koblingen.

Hvis du videresender i stedet for å dytte innstillinger, videresend navnerommet den private sonen eier, privatelink.azurewebsites.net i stedet for hele azurewebsites.net. En betinget videresender som sluker hele overordnet suffiks, sender hvert oppslag for tjenesten til Azure, også de som skulle blitt lokale.

Bruk navnet sertifikatet ble utstedt til

Når adressen er riktig, dukker den andre feilen opp. Lagring og App Service publiserer et privatelink-alias, og det aliaset er ikke nødvendigvis navnet i sertifikatet. En AzCopy-opplasting rettet mot privatelink.blob.core.windows.net besto ikke valideringen; samme opplasting til <account>.blob.core.windows.net/<container> ble slått opp til den private adressen og gikk gjennom, så den ble værende på den private veien uten noen overstyring.

Regelen gjelder i en nettleser og også for App Service: koble til med vertsnavnet sertifikatet dekker, og la DNS levere den private adressen. Ikke grip til en omgåelse av valideringen, for det gjør en navnefeil til en sikkerhetsregresjon. En vellykket ping beviser ruten og sier ingenting om navnet inne i håndtrykket, og derfor blir disse stående som separate kontroller.

En rekkefølge på fire trinn som isolerer hvert lag

1. Bekreft at VPN-klienten har en adresse fra point-to-site-poolen og en rute til endepunktets private adresse.
2. Slå opp det nøyaktige navnet applikasjonen bruker, og sammenlign svaret med endepunktets adresse.
3. Åpne en TCP-forbindelse til endepunktet på tjenesteporten, og les deretter sertifikatnavnet som presenteres på den forbindelsen.
4. Test først nå autorisasjon, fordi en fungerende vei og et gyldig sertifikat fortsatt ikke gir tilgang til ressursen.

En avvist forbindelse mens adressen er riktig peker på nettverkssikkerhetsgruppen eller tilstanden til den private endepunktforbindelsen, ikke på DNS, så kontroller dem før du redigerer resolverinnstillingene igjen. Et TLS-navneavvik sender deg tilbake til vertsnavnet i URL-en og sertifikatets subject. Hold oppslagets utdata, sertifikatnavnet og den nøyaktige URL-en sammen; disse tre verdiene forklarer de fleste av disse tilfellene uten å røre gatewayen.

Bruk en VM inne i det virtuelle nettverket som kontroll. Hvis navnet slås opp privat der og offentlig fra tunnelen, er sonen og posten riktige, og den eneste forskjellen er klientens resolvervei, som er raskere å bekrefte enn nok en gjennomgang av endepunktkonfigurasjonen.

Klienter bufrer også. En post som svarte offentlig for ti minutter siden, fortsetter å svare etter at du har rettet sonen, så tøm bufferen før du tester på nytt. På Windows rydder ipconfig /flushdns klientbufferen; regler for navneoppløsningspolicy består, bestemmer hvilket suffiks som går til hvilken server, og kan fortsette å sende navnerommet til resolveren du nettopp erstattet.

Hvor en hosts-oppføring hører hjemme

Å legge endepunktets adresse i en hosts-fil er god diagnostikk og dårlig design. Det beviser at navn-til-adresse-mappingen er den manglende brikken, og lar deg teste alt etter det trinnet, men det er usynlig for brukerne dine, går i stykker når endepunktets adresse endres, og skjuler sonen som skulle svare.

En gjenglemt testoppføring er verre enn en gammel buffer, fordi den kan få den reparerte veien til å se brutt ut eller den brutte veien til å se reparert ut, avhengig av feilens retning. Fjern den før den siste kjøringen, og slå bare opp med produksjonsresolveren.

Korte navn trenger et søkesuffiks, og fullt kvalifiserte navn gjør det ikke, så test det fullt kvalifiserte navnet først, og avgjør deretter om arbeidsflyten trenger et suffiks som dyttes gjennom klientprofilen. Microsoft dokumenterer sonenavnene og postformatene per tjeneste i sine DNS-retningslinjer for private endepunkter; les posten for tjenesten din i stedet for å kopiere en sone fra en annen.