Waarom een privé-eindpunt nog steeds met een openbaar adres antwoordt

De laptop maakt verbinding, de tunnel meldt zich actief, en het opslagaccount weigert nog steeds elk verzoek. Het privé-eindpunt bestaat, de route naar het subnet bestaat, en de naam antwoordt ofwel met een openbaar adres ofwel wordt helemaal niet opgelost. Aan de tunnel is niets mis: de client is nooit verteld welke server voor die naam zou moeten antwoorden. Volg de query naar buiten en de kloof wordt zichtbaar.

Begin bij de resolver van de client

Vraag de client welke server hij bevraagt terwijl de tunnel actief is. Een point-to-site-profiel levert dat adres, en een profiel dat niets levert laat het besturingssysteem terugvallen op de standaardwaarden van de adapter.

Openbare resolvers hebben geen zicht op een privézone, dus antwoorden ze vanaf het internet, wat precies hun taak is. De eerste controle is daarom het resolveradres dat in gebruik is, niet de tunnel en niet het eindpunt.

Lees wat het antwoord werkelijk is

Los de servicenaam op en lees het adres dat terugkomt. Een openbaar antwoord betekent dat de query een server heeft bereikt die de zone niet kan zien. Geen antwoord betekent dat de naam alleen privé bestaat en dat niets wat de client kan bereiken hem vasthoudt.

Die twee uitkomsten veroorzaken vergelijkbare applicatiefouten en horen bij verschillende eigenaren. De ene is een resolver-keuzeprobleem, de andere is een ontbrekende zonekoppeling.

Een hosts-regel bewijst het pad en liegt daarna

Het eindpuntadres in het lokale hosts-bestand zetten is de snelste manier om te bewijzen dat de tunnel en de firewall van de service al werken. Als het verzoek met die regel slaagt, is alleen de naamresolutie stuk. Het is ook een wijziging per machine die precies één naam dekt.

Het helpt het tweede account, het tweede eindpunt of een collega niet, en het breekt zonder waarschuwing wanneer het eindpunt op een nieuw adres opnieuw wordt aangemaakt.

Erger nog, het laat je machine anders gedragen dan die van iedereen, en zo overleeft een resolverfout een week onderzoek. Gebruik het om het pad te bevestigen, haal het er dan uit en verhelp de oorzaak.

Koppel de zone en deel een resolver uit

Twee voorwaarden moeten tegelijk gelden. De privézone moet gekoppeld zijn aan het virtuele netwerk waar het eindpunt woont, en de client moet zijn queries naar een server sturen die die zone kan lezen. Een inkomend eindpunt van DNS Private Resolver levert zo'n adres binnen het netwerk en beantwoordt queries die via de tunnel binnenkomen. Zet dat adres in het VPN-profiel en voeg het privé-achtervoegsel toe dat de client moet toepassen.

Een bestaande on-premises resolver kan hetzelfde resultaat bereiken via een voorwaardelijke doorstuurder die op de zone is gericht.

Netwerkregels op de resolver tellen even zwaar als routing. Als de inkomende regel het bereik van de VPN-clients uitsluit, verlopen queries in plaats van een verkeerd antwoord te geven. Dat verlopen is wat mensen terugstuurt naar een routetabel waarin niets mis is.

Controleer naam, poort en identiteit in volgorde

Werk in volgorde: los de naam op, bevestig dat het antwoord privé is, open de poort en doe dan een geauthenticeerd verzoek. Elke fase heeft zijn eigen eigenaar en zijn eigen storingssignatuur.

Een privéantwoord gevolgd door een time-out wijst op een route of een firewall. Een openbaar antwoord wijst op de resolver. Een voltooide verbinding die een identiteitsfout teruggeeft, hoort bij de service.

Nog een storing hoort op deze lijst. Een servicefirewall die een clientadres toestaat, komt niet meer overeen wanneer de pool dat adres na een herverbinding aan een andere sessie geeft. Lees het aanroepersadres dat de service heeft vastgelegd, niet datgene waarvan de client denkt dat hij het heeft. De twee zijn het vaker oneens dan mensen verwachten. De richtlijnen voor Azure DNS Private Resolver behandelen de zonekoppeling en de doorstuurinrichting.