Azure P2S VPN kan de naam van een privé-eindpunt niet omzetten

Je maakt de point-to-site-tunnel, pingt het privéadres, opent de app en krijgt in plaats daarvan een 403 of een certificaatfout. Beide symptomen wijzen op DNS, maar het zijn verschillende fouten: het ene betekent dat de client het openbare adres heeft omgezet, het andere dat hij het privéadres heeft omgezet en vervolgens een naam aanbood die het certificaat niet dekt. Loop de controles hieronder in volgorde na en stop bij de eerste fout, want een hosts-regel of een gecacht antwoord kan elke latere controle om de verkeerde reden laten slagen. Ik bewaar deze volgorde in een tekstbestand naast mijn VPN-profielen, omdat de oplossing niets aan de tunnel verandert en alles aan wat de client weet.

Begin met het adres dat de client echt krijgt

Vraag het de resolver rechtstreeks in plaats van de toepassing te vertrouwen. Op Windows laat nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net zien welke weergave de client heeft gekregen. Een openbaar antwoord betekent dat niets verderop het eindpunt zal bereiken; het privéadres van het eindpunt betekent dat DNS klaar is en dat de volgende controle de verbinding zelf is.

Een privé-eindpunt hernoemt de service niet. Het account of de app behoudt zijn gewone volledig gekwalificeerde naam, en het eindpunt verandert alleen het adres waarop die naam voor clients binnen het virtuele netwerk wordt omgezet. Daarom wordt dezelfde hostnaam privé omgezet vanaf een VM in het netwerk en openbaar vanaf een laptop die nooit de privéweergave heeft gekregen.

Controleer de zone, de koppeling en de record vóór de tunnel

Drie voorwaarden moeten samen gelden: de privézone bestaat, hij is gekoppeld aan het virtuele netwerk waar de VPN-gateway en de clients Azure binnenkomen, en hij bevat een A-record voor het eindpunt dat naar het privéadres wijst. Koppel de zone aan een ongerelateerd netwerk en de gateway blijft de openbare record omzetten terwijl alles aan de tunnel er gezond uitziet.

Zonenamen horen bij services, niet in het algemeen bij privékoppelingen. App Service gebruikt meestal privatelink.azurewebsites.net, opslag en SQL hebben hun eigen naamruimten, en de zone van een andere service lenen levert een zone op die bestaat en niets nuttigs beantwoordt.

Geef de client een resolver die hij echt kan bereiken

168.63.129.16 antwoordt vanaf virtuele Azure-machines en is geen DNS-server voor een laptop aan de andere kant van een point-to-site-tunnel. De client heeft een resolver nodig die via de tunnel bereikbaar is: een inkomend eindpunt van Azure DNS Private Resolver, een doorstuurder binnen het virtuele netwerk, of DNS-serverregels die in het VPN-clientprofiel worden meegedragen zodat de client het virtuele netwerk rechtstreeks vraagt.

Een geconfigureerde maar onbereikbare resolver gedraagt zich precies als geen resolver, en het symptoom is een time-out in plaats van een verkeerd antwoord, waardoor het als firewallprobleem wordt gelezen. Test hem met een query die de tunnel hoort te dragen, niet met een openbare naam die via de lokale koppeling toch zou lukken.

Als je doorstuurt in plaats van instellingen te pushen, stuur dan de naamruimte door die de privézone bezit, privatelink.azurewebsites.net in plaats van heel azurewebsites.net. Een voorwaardelijke doorstuurder die het hele bovenliggende achtervoegsel opslokt, stuurt elke zoekopdracht voor de service naar Azure, ook de zoekopdrachten die lokaal zouden moeten blijven.

Gebruik de naam waarvoor het certificaat is uitgegeven

Zodra het adres klopt, komt de tweede fout boven. Opslag en App Service publiceren een privatelink-alias, en die alias is niet per se de naam in het certificaat. Een AzCopy-upload naar privatelink.blob.core.windows.net faalde de validatie; dezelfde upload naar <account>.blob.core.windows.net/<container> werd naar het privéadres omgezet en slaagde, dus bleef hij op het privépad zonder enige omzeiling.

De regel geldt in een browser en ook voor App Service: verbind met de hostnaam die het certificaat dekt en laat DNS het privéadres leveren. Grijp niet naar het omzeilen van de validatie, want dat maakt van een naamfout een beveiligingsregressie. Een geslaagde ping bewijst de route en zegt niets over de naam in de handshake, daarom blijven dit aparte controles.

Een volgorde van vier stappen die elke laag isoleert

1. Bevestig dat de VPN-client een adres uit de point-to-site-pool heeft en een route naar het privéadres van het eindpunt.
2. Zet de exacte naam om die de toepassing gebruikt en vergelijk het antwoord met het adres van het eindpunt.
3. Open een TCP-verbinding naar het eindpunt op de servicepoort en lees dan de certificaatnaam die op die verbinding wordt gepresenteerd.
4. Test nu pas de autorisatie, want een werkend pad en een geldig certificaat geven nog geen toegang tot de resource.

Een geweigerde verbinding terwijl het adres klopt wijst op de netwerkbeveiligingsgroep of de verbindingsstatus van het privé-eindpunt, niet op DNS, dus controleer die voordat je de resolverinstellingen opnieuw bewerkt. Een TLS-naamafwijking stuurt je terug naar de hostnaam in de URL en het subject van het certificaat. Houd de uitvoer van de omzetting, de certificaatnaam en de exacte URL bij elkaar; die drie waarden verklaren de meeste van deze gevallen zonder de gateway aan te raken.

Gebruik een VM binnen het virtuele netwerk als controle. Wordt de naam daar privé en vanaf de tunnel openbaar omgezet, dan zijn de zone en de record correct en is het enige verschil het resolverpad van de client, wat sneller te bevestigen is dan nog een ronde langs de eindpuntconfiguratie.

Clients cachen ook. Een record dat tien minuten geleden openbaar antwoordde, blijft antwoorden nadat je de zone hebt gerepareerd, dus leeg de cache voordat je opnieuw test. Op Windows wist ipconfig /flushdns de clientcache; regels voor naamomzettingsbeleid blijven bestaan, bepalen welk achtervoegsel naar welke server gaat en kunnen de naamruimte blijven sturen naar de resolver die je net hebt vervangen.

Waar een hosts-regel hoort

Het adres van het eindpunt in een hosts-bestand zetten is een goede diagnose en een slecht ontwerp. Het bewijst dat de koppeling van naam aan adres het ontbrekende stuk is en laat je alles daarna testen, maar het is onzichtbaar voor je gebruikers, breekt wanneer het adres van het eindpunt verandert en verbergt de zone die zou moeten antwoorden.

Een achtergebleven testregel is erger dan een verouderde cache, omdat hij het gerepareerde pad kapot of het kapotte pad gerepareerd kan laten lijken, afhankelijk van de richting van de fout. Verwijder hem vóór de laatste ronde en zet alleen om met de productieresolver.

Korte namen hebben een zoekachtervoegsel nodig en volledig gekwalificeerde namen niet, dus test eerst de volledig gekwalificeerde naam en beslis dan of de werkstroom een achtervoegsel nodig heeft dat via het clientprofiel wordt gepusht. Microsoft documenteert de zonenaam en recordvormen per service in zijn DNS-richtlijnen voor privé-eindpunten; lees de regel voor jouw service in plaats van een zone van een andere te kopiëren.