Azure P2S VPN kan inte matcha namnet för en privat slutpunkt

Du ansluter point-to-site-tunneln, pingar den privata adressen, öppnar appen och får i stället en 403 eller ett certifikatfel. Båda symptomen pekar på DNS, men de är olika fel: det ena betyder att klienten matchade den offentliga adressen, det andra att den matchade den privata adressen och sedan erbjöd ett namn som certifikatet inte täcker. Gå igenom kontrollerna nedan i ordning och stanna vid första felet, eftersom en hosts-post eller ett cachat svar kan få varje senare kontroll att lyckas av fel anledning. Jag har den här ordningen i en textfil bredvid mina VPN-profiler, eftersom åtgärden inte ändrar något i tunneln och allt i vad klienten vet.

Börja med adressen som klienten faktiskt får

Fråga resolvern direkt i stället för att lita på applikationen. I Windows visar nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net vilken vy klienten fick. Ett offentligt svar betyder att inget längre ned når slutpunkten; slutpunktens privata adress betyder att DNS är klart och att nästa kontroll är själva anslutningen.

En privat slutpunkt bytar inte namn på tjänsten. Kontot eller appen behåller sitt vanliga fullständiga namn, och slutpunkten ändrar bara den adress som namnet matchas till för klienter i det virtuella nätverket. Därför matchas samma värdnamn privat från en VM i nätverket och offentligt från en bärbar dator som aldrig fick den privata vyn.

Kontrollera zonen, dess länk och posten före tunneln

Tre villkor måste gälla samtidigt: den privata zonen finns, den är länkad till det virtuella nätverk där VPN-gatewayen och klienterna går in i Azure, och den innehåller en A-post för slutpunkten som pekar på den privata adressen. Länka zonen till ett orelaterat nätverk och gatewayen fortsätter matcha den offentliga posten medan allt vid tunneln ser friskt ut.

Zonnamn tillhör tjänster, inte privata länkar i allmänhet. App Service använder vanligen privatelink.azurewebsites.net, lagring och SQL har egna namnrymder, och att låna en annan tjänsts zon ger en zon som finns och inte svarar något användbart.

Ge klienten en resolver som den faktiskt kan nå

168.63.129.16 svarar från virtuella Azure-datorer och är inte en DNS-server för en bärbar dator på andra sidan en point-to-site-tunnel. Klienten behöver en resolver som nås genom tunneln: en inkommande slutpunkt i Azure DNS Private Resolver, en vidarebefordrare i det virtuella nätverket, eller DNS-serverposter som bärs i VPN-klientprofilen så att klienten frågar det virtuella nätverket direkt.

En konfigurerad men onåbar resolver beter sig precis som ingen resolver, och symptomet är en timeout i stället för ett felaktigt svar, vilket är varför det läses som ett brandväggsproblem. Testa den med en fråga som tunneln ska bära, inte med ett offentligt namn som ändå skulle lyckas över den lokala länken.

Om du vidarebefordrar i stället för att skjuta ut inställningar, vidarebefordra namnrymden som den privata zonen äger, privatelink.azurewebsites.net i stället för hela azurewebsites.net. En villkorad vidarebefordrare som slukar hela föräldrasuffixet skickar varje sökning för tjänsten till Azure, även de som borde stanna lokalt.

Använd namnet som certifikatet utfärdades för

När adressen är rätt dyker det andra felet upp. Lagring och App Service publicerar ett privatelink-alias, och det aliaset är inte nödvändigtvis namnet i certifikatet. En AzCopy-uppladdning mot privatelink.blob.core.windows.net klarade inte valideringen; samma uppladdning till <account>.blob.core.windows.net/<container> matchades till den privata adressen och gick igenom, så den stannade på den privata vägen utan någon kringgång.

Regeln gäller i en webbläsare och även för App Service: anslut med värdnamnet som certifikatet täcker och låt DNS leverera den privata adressen. Ta inte till en kringgång av valideringen, för den gör ett namnfel till en säkerhetsregression. En lyckad ping bevisar vägen och säger inget om namnet inne i handskakningen, därför är detta fortsatt separata kontroller.

En ordning i fyra steg som isolerar varje lager

1. Bekräfta att VPN-klienten har en adress från point-to-site-poolen och en väg till slutpunktens privata adress.
2. Matcha det exakta namn som applikationen använder och jämför svaret med slutpunktens adress.
3. Öppna en TCP-anslutning till slutpunkten på tjänsteporten och läs sedan certifikatnamnet som presenteras på den anslutningen.
4. Testa först nu auktoriseringen, eftersom en fungerande väg och ett giltigt certifikat fortfarande inte ger åtkomst till resursen.

En nekad anslutning medan adressen är korrekt pekar på nätverkssäkerhetsgruppen eller tillståndet för den privata slutpunktsanslutningen, inte på DNS, så kontrollera dem innan du redigerar resolverinställningarna igen. En TLS-namnavvikelse skickar dig tillbaka till värdnamnet i URL:en och certifikatets subject. Håll ihop utdata från matchningen, certifikatnamnet och den exakta URL:en; de tre värdena förklarar de flesta av dessa fall utan att röra gatewayen.

Använd en VM i det virtuella nätverket som kontroll. Om namnet matchas privat där och offentligt från tunneln är zonen och posten korrekta och den enda skillnaden är klientens resolverväg, vilket bekräftas snabbare än ännu en genomgång av slutpunktskonfigurationen.

Klienter cachar också. En post som svarade offentligt för tio minuter sedan fortsätter svara efter att du rättat zonen, så töm cachen innan du testar igen. I Windows rensar ipconfig /flushdns klientcachen; regler för namnmatchningspolicy finns kvar, avgör vilket suffix som går till vilken server och kan fortsätta skicka namnrymden till den resolver du just ersatte.

Var en hosts-post hör hemma

Att lägga slutpunktens adress i en hosts-fil är god diagnostik och dålig design. Det bevisar att namn-till-adress-mappningen är den saknade pusselbiten och låter dig testa allt efter det steget, men det är osynligt för dina användare, går sönder när slutpunktens adress ändras och döljer zonen som borde svara.

En kvarglömd testpost är värre än en gammal cache, eftersom den kan få den reparerade vägen att se trasig ut eller den trasiga vägen att se reparerad ut, beroende på felets riktning. Ta bort den före den sista körningen och matcha bara med produktionsresolvern.

Korta namn behöver ett söksuffix och fullständiga namn inte, så testa det fullständiga namnet först och avgör sedan om arbetsflödet behöver ett suffix som skjuts ut via klientprofilen. Microsoft dokumenterar zonnamnen och postformerna per tjänst i sina DNS-riktlinjer för privata slutpunkter; läs posten för din tjänst i stället för att kopiera en zon från en annan.