Azure P2S VPN kan ikkje slå opp namnet til eit privat endepunkt

Du koplar til point-to-site-tunnelen, pingar den private adressa, opnar appen og får i staden ein 403 eller ein sertifikatfeil. Begge symptoma peikar på DNS, men dei er ulike feil: den eine tyder at klienten slo opp den offentlege adressa, den andre at han slo opp den private adressa og deretter baud eit namn sertifikatet ikkje dekkjer. Gå gjennom kontrollane nedanfor i rekkjefølgje og stopp ved første feil, fordi ein hosts-oppføring eller eit svarsýn i mellomlageret kan få kvar seinare kontroll til å bestå av feil grunn. Eg har denne rekkjefølgja i ei tekstfil ved sida av VPN-profilane mine, fordi rettinga ikkje endrar noko ved tunnelen og alt ved det klienten veit.

Byrja med adressa klienten faktisk får

Spør resolveren direkte i staden for å stole på applikasjonen. På Windows viser nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net kva vising klienten fekk. Eit offentleg svar tyder at ingenting lenger nede når endepunktet; den private adressa til endepunktet tyder at DNS er ferdig og at neste kontroll er sjølve sambandet.

Eit privat endepunkt gjev ikkje tenesta nytt namn. Kontoen eller appen held på det vanlege fullt kvalifiserte namnet sitt, og endepunktet endrar berre adressa namnet blir slått opp til for klientar inne i det virtuelle nettet. Difor blir same vertsnamn slått opp privat frå ein VM i nettet og offentleg frå ein berbar maskin som aldri fekk den private visinga.

Kontroller sona, koplinga og posten før tunnelen

Tre vilkår må gjelde samstundes: den private sona finst, ho er kopla til det virtuelle nettet der VPN-gatewayen og klientane går inn i Azure, og ho inneheld ein A-post for endepunktet som peikar på den private adressa. Koplar du sona til eit uvedkommande nett, held gatewayen fram med å slå opp den offentlege posten medan alt ved tunnelen ser friskt ut.

Sonenamn høyrer til tenester, ikkje private koplingar generelt. App Service brukar vanlegvis privatelink.azurewebsites.net, lagring og SQL har eigne namnerom, og å låne sona til ei anna teneste gjev ei sone som finst og ikkje svarar noko nyttig.

Gje klienten ein resolver han faktisk kan nå

168.63.129.16 svarar frå virtuelle Azure-maskinar og er ikkje ein DNS-server for ein berbar maskin på den andre sida av ein point-to-site-tunnel. Klienten treng ein resolver som er tilgjengeleg gjennom tunnelen: eit innkomande endepunkt i Azure DNS Private Resolver, ein vidaresendar inne i det virtuelle nettet, eller DNS-serveroppføringar som blir borne i VPN-klientprofilen slik at klienten spør det virtuelle nettet direkte.

Ein konfigurert, men utilgjengeleg resolver oppfører seg akkurat som ingen resolver, og symptomet er tidsavbrot i staden for eit feil svar, og difor blir det lese som eit brannmurproblem. Test han med eit spørsmål tunnelen skal bera, ikkje med eit offentleg namn som uansett ville lukkast over den lokale koplinga.

Vidaresender du i staden for å dytte innstillingar, vidaresend namnerommet den private sona eig, privatelink.azurewebsites.net i staden for heile azurewebsites.net. Ein vilkårsvidaresendar som slukar heile overordna suffiks, sender kvart oppslag for tenesta til Azure, også dei som skulle blitt lokale.

Bruk namnet sertifikatet vart utstedt til

Når adressa er rett, kjem den andre feilen fram. Lagring og App Service publiserer eit privatelink-alias, og det aliaset er ikkje nødvendigvis namnet i sertifikatet. Ei AzCopy-opplasting retta mot privatelink.blob.core.windows.net klarte ikkje valideringa; same opplasting til <account>.blob.core.windows.net/<container> vart slått opp til den private adressa og gjekk gjennom, så ho vart verande på den private vegen utan noka overstyring.

Regelen gjeld i ein nettlesar og også for App Service: kople til med vertsnamnet sertifikatet dekkjer, og lat DNS levere den private adressa. Ikkje grip til ei omgåing av valideringa, for det gjer ein namnefeil til ein tryggleiksregresjon. Ein vellukka ping provar ruta og seier ingenting om namnet inne i handtrykket, og difor blir desse ståande som separate kontrollar.

Ei rekkjefølgje på fire steg som isolerer kvart lag

1. Stadfest at VPN-klienten har ei adresse frå point-to-site-bassenget og ei rute til den private adressa til endepunktet.
2. Slå opp det nøyaktige namnet applikasjonen brukar, og samanlikn svaret med adressa til endepunktet.
3. Opne ein TCP-samband til endepunktet på tenesteporten, og les deretter sertifikatnamnet som blir presentert på det sambandet.
4. Test først no autorisasjon, fordi ein fungerande veg og eit gyldig sertifikat framleis ikkje gjev tilgang til ressursen.

Eit avvist samband medan adressa er rett peikar på nettverkssikkerheitsgruppa eller tilstanden til den private endepunktkoplinga, ikkje på DNS, så kontroller dei før du redigerer resolverinnstillingane igjen. Eit TLS-namneavvik sender deg tilbake til vertsnamnet i URL-en og subject i sertifikatet. Hald utdata frå oppslaget, sertifikatnamnet og den nøyaktige URL-en saman; desse tre verdiane forklarer dei fleste av desse tilfella utan å røre gatewayen.

Bruk ein VM inne i det virtuelle nettet som kontroll. Blir namnet slått opp privat der og offentleg frå tunnelen, er sona og posten rette, og den einaste skilnaden er resolvervegen til klienten, som er raskare å stadfeste enn nok ein gjennomgang av endepunktkonfigurasjonen.

Klientar lagrar også i mellomlager. Ein post som svara offentleg for ti minutt sidan, held fram med å svare etter at du har retta sona, så tøm mellomlageret før du testar på nytt. På Windows ryddar ipconfig /flushdns klientmellomlageret; reglar for namneoppløysingspolicy blir verande, avgjer kva suffiks som går til kva server, og kan halde fram med å sende namnerommet til resolveren du nettopp bytte ut.

Kvar ein hosts-oppføring høyrer heime

Å leggje adressa til endepunktet i ei hosts-fil er god diagnostikk og dårleg design. Det provar at namne-til-adresse-mappinga er den manglande biten, og lèt deg teste alt etter det steget, men det er usynleg for brukarane dine, går i stykker når adressa til endepunktet blir endra, og skjuler sona som skulle svare.

Ein gløymd testoppføring er verre enn eit gammalt mellomlager, fordi han kan få den reparerte vegen til å sjå broten ut eller den brotne vegen til å sjå reparert ut, avhengig av retninga på feilen. Fjern han før den siste køyringa, og slå berre opp med produksjonsresolveren.

Korte namn treng eit søkjesuffiks, og fullt kvalifiserte namn gjer det ikkje, så test det fullt kvalifiserte namnet først, og avgjer deretter om arbeidsflyten treng eit suffiks som blir dytta gjennom klientprofilen. Microsoft dokumenterer sonenamna og postformata per teneste i sine DNS-retningslinjer for private endepunkt; les posten for tenesta di i staden for å kopiere ei sone frå ei anna.