Azure P2S-DNS schlägt fehl, wenn der Resolver in einem gepeerten VNet liegt

Ein Client erreicht sein eigenes virtuelles Netzwerk und kann Namen in einem gepeerten Netzwerk trotzdem nicht auflösen. Peering ist kein Gateway-Transit, solange nicht beide Seiten zustimmen.

Pingen Sie die VM an, und sie antwortet; fragen Sie nach ihrem Namen, und der Client meldet, der Host sei unbekannt. Liegt der Resolver in einem gepeerten virtuellen Netzwerk statt in dem, das das VPN-Gateway enthält, ist dieses Ergebnispaar zu erwarten, und keine noch so gründliche Resolver-Fehldiagnose ändert daran etwas. Es fehlt ein Routing-Vertrag, den Peering standardmäßig zurückhält. Zwei Topologien sehen auf dem Papier fast gleich aus, und der Unterschied zwischen funktionierend und defekt ist ein Paar Peering-Schalter, die in die richtige Richtung gestellt sind.

Stellen Sie sich ein Laptop vor, das in ein Gateway in VNet2 tunnelt, während der Domänencontroller, der DNS bereitstellt, in VNet1 sitzt.

Zwei Topologien, ein Unterschied

Legen Sie den Resolver in das eigene virtuelle Netzwerk des Gateways, und der Name wird aufgelöst, sobald der Tunnel steht. Keine Peering-Einstellung wirkt an dieser Auflösung mit.

Verschieben Sie denselben Resolver über ein Peering, und der Client erhält weiterhin eine Antwort von der VM, während der Name unbekannt bleibt. Zertifikat, Tunnel und Client sind unverändert. Das Einzige, was sich bewegt hat, ist der Standort des Resolvers. Das Peering gab ihm eine Route zu dieser Adresse, nicht dem Gateway die Befugnis, Verkehr dorthin zu tragen.

Seite A: Gateway-Transit beim Gateway-Eigentümer erlauben

Ein Peering verbindet zwei virtuelle Netzwerke, doch die Verbindung ist nicht transitiv für Verkehr, der über ein Gateway eintrifft, und eine Point-to-Site-Anfrage trifft genau so ein. Das Gateway in VNet2 hat daher keine Grundlage, die Auflösung an VNet1 zu übergeben, bis das Design es erlaubt. Die Erlaubnis ist ein Schalter am Peering, das dem Netzwerk mit dem Gateway gehört.

Setzen Sie Allow gateway transit am Peering von VNet2 in Richtung VNet1. Die Eigenschaft gehört zum Peering-Objekt, nicht zur Gateway-Ressource, deshalb lesen und ändern Sie sie im Peering-Blade. Das ist die ganze Seite A.

Seite B: entfernte Gateways beim Peer verwenden

Die andere Hälfte ist das Spiegelbild: Aktivieren Sie am Peering von VNet1 zurück zu VNet2 die Option Use remote gateways. Denselben Schalter an beiden Enden oder nur an einem Ende einzuschalten, hinterlässt einen halb gebauten Pfad und das ursprüngliche Symptom unverändert. Nur das Netzwerk mit dem VPN-Gateway erlaubt Transit, und der Peer ist die Seite, die ihn nutzt.

Lesen Sie beide Eigenschaften auf beiden Netzwerken, statt dem Portal-Blade zu vertrauen, das Sie zuletzt geöffnet haben.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Das Paar nebeneinander zu sehen ist der schnellste Weg, eine umgekehrte Einstellung zu erwischen. Ein Peering, das auf der Gateway-Seite AllowGatewayTransit false meldet, erklärt den gesamten Fehler ohne Paketmitschnitt.

Was der Client trotzdem erhalten muss

Routing ist notwendig und nicht ausreichend, denn das Point-to-Site-Profil muss dem Client auch eine DNS-Adresse übergeben, die antwortet, sobald der Transit funktioniert. Der Plattform-Resolver ist diese Adresse nicht: Er beantwortet Azure Private DNS-Zonen, die mit dem virtuellen Netzwerk verknüpft sind, aber nichts für eine Zone, die auf Ihren eigenen Verzeichnisservern gehostet wird, und genau das nutzt diese Bereitstellung. Richten Sie einen Client darauf, und öffentliche Namen werden fröhlich aufgelöst, während der interne Host unbekannt bleibt.

Fragen Sie den Resolver vom verbundenen Laptop aus ab, bevor Sie etwas anderes ändern.

nslookup dc01.corp.example 10.1.0.4

Eine Zeitüberschreitung sagt, dass der Pfad noch fehlt. Eine autoritative Antwort schiebt das Problem zurück zum Client, meist ein Suffix, das nie angehängt wird, sodass kurze Namen zu einem öffentlichen Resolver wandern, der sie fröhlich scheitern lässt.

Vergleichen Sie denselben Vertrag auf der Site-to-Site-Seite

Nichts davon gehört speziell zu Laptops. Tauschen Sie den Client gegen eine Filiale bei Site-to-Site, und die zweiseitige Anforderung kehrt zurück: Die Filiale kommt direkt im Gateway-Netzwerk an, und ein Dienst zwei Netzwerke weiter liegt weiterhin hinter dem Peering.

Transit muss an beiden Peerings gewährt werden, und der Schalter, der ihn gewährt, sitzt am Peering und nicht am Client-Typ.

Bevor Sie das Gateway beschuldigen

Windows führt pro Adapter eine Resolver-Liste, prüfen Sie also, was die Tunnel-Schnittstelle tatsächlich erhalten hat, bevor Sie das Gateway beschuldigen.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Eine negative Antwort überlebt die Routing-Korrektur im Cache, und eine veraltete Suffix-Liste schickt Abfragen weiter an eine Stelle, die die Zone nie gehostet hat. Leeren Sie den Cache, fragen Sie erneut, und notieren Sie, welcher Server antwortet.

Zwei kleinere Bedingungen entscheiden, ob der Pfad hält: die Adressräume dürfen sich nicht überlappen, und die Netzwerksicherheitsgruppe im Subnetz des Resolvers muss den Client-Pool zulassen, der nur ein weiterer Quellbereich ist. Beweisen Sie es mit einer Effektivrouten-Prüfung von der VM-Seite plus einer direkten Abfrage vom Client, damit ein Zonenproblem, ein Suffixproblem oder ein Filter nie mit fehlendem Transit verwechselt wird.

Ähnliche Artikel