Azure P2S-DNS mislukt wanneer de resolver in een gepeerd VNet staat

Ping de VM en hij antwoordt; vraag naar zijn naam en de client zegt dat de host onbekend is. Wanneer de resolver in een gepeerd virtueel netwerk staat in plaats van in het netwerk met de VPN-gateway, is dat paar uitkomsten te verwachten, en geen enkele hoeveelheid resolver-diagnose verandert dat. Wat ontbreekt, is een routeringscontract dat peering standaard achterhoudt. Twee topologieën lijken op papier bijna identiek, en het verschil tussen werkend en stuk is een paar peering-schakelaars die de juiste kant op staan.

Stel je een laptop voor die naar een gateway in VNet2 tunnelt, terwijl de domeincontroller die DNS levert in VNet1 zit.

Twee topologieën, één verschil

Zet de resolver in het eigen virtuele netwerk van de gateway en de naam wordt opgelost op het moment dat de tunnel omhoog komt. Geen enkele peering-instelling doet aan die opzoeking mee.

Verplaats dezelfde resolver over een peering en de client krijgt nog steeds antwoord van de VM terwijl de naam onbekend blijft. Certificaat, tunnel en client zijn onveranderd. Het enige dat verschoof, is waar de resolver woont. Peering gaf hem een route naar dat adres, niet de bevoegdheid aan de gateway om daar verkeer heen te dragen.

Kant A: sta gateway-transit toe bij de gateway-eigenaar

Een peering verbindt twee virtuele netwerken, maar de verbinding is niet transitief voor verkeer dat via een gateway binnenkomt, en een point-to-site-aanvraag komt precies zo binnen. De gateway in VNet2 heeft daarom geen grond om de opzoeking aan VNet1 over te dragen tot het ontwerp dat toestaat. De toestemming is een schakelaar op de peering die eigendom is van het netwerk met de gateway.

Stel Allow gateway transit in op de peering van VNet2 richting VNet1. De eigenschap hoort bij het peering-object, niet bij de gateway-resource, dus je leest en wijzigt hem in de peering-blade. Dat is heel kant A.

Kant B: gebruik externe gateways aan de peer-kant

De andere helft is het spiegelbeeld: op de peering van VNet1 terug naar VNet2 schakel je Use remote gateways in. Dezelfde vlag aan beide uiteinden, of maar aan één, laat een half gebouwde route en het oorspronkelijke symptoom ongemoeid. Alleen het netwerk met de VPN-gateway staat transit toe, en de peer is de kant die hem gebruikt.

Lees beide eigenschappen op beide netwerken in plaats van de portal-blade te vertrouwen die je het laatst opende.

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

Het paar naast elkaar zien is de snelste manier om een omgekeerde instelling te vangen. Een peering die aan de gateway-kant AllowGatewayTransit false meldt, verklaart de hele storing zonder pakketopname.

Wat de client nog steeds moet ontvangen

Routering is noodzakelijk en niet voldoende, want het point-to-site-profiel moet de client ook een DNS-adres geven dat antwoordt zodra de transit werkt. De platform-resolver is dat adres niet: hij antwoordt voor Azure Private DNS-zones die aan het virtuele netwerk zijn gekoppeld, maar niets voor een zone die op je eigen directoryservers wordt gehost, en dat is wat deze uitrol gebruikt. Wijs een client daarheen en openbare namen lossen vrolijk op terwijl de interne host onbekend blijft.

Vraag de resolver vanaf de verbonden laptop voordat je iets anders wijzigt.

nslookup dc01.corp.example 10.1.0.4

Een time-out zegt dat de route nog ontbreekt. Een gezaghebbend antwoord duwt het probleem terug naar de client, meestal een suffix dat nooit wordt toegevoegd, zodat korte namen naar een openbare resolver reizen die ze vrolijk laat mislukken.

Vergelijk hetzelfde contract aan de site-to-site-kant

Niets hiervan is specifiek voor laptops. Vervang de client door een filiaal bij site-to-site en de tweezijdige eis komt terug: het filiaal komt rechtstreeks in het gateway-netwerk aan, en een dienst twee netwerken verder ligt nog steeds achter de peering.

Transit moet op beide peerings worden verleend, en de schakelaar die dat doet, zit op de peering en niet op het clienttype.

Voordat je de gateway de schuld geeft

Windows houdt per adapter een resolverlijst bij, dus bevestig wat de tunnel-interface werkelijk heeft ontvangen voordat je de gateway de schuld geeft.

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

Een negatief antwoord overleeft de routeringscorrectie in de cache, en een verouderde suffixlijst blijft query's sturen naar een plek die de zone nooit heeft gehost. Leeg, vraag opnieuw, en noteer welke server antwoordt.

Twee kleinere voorwaarden bepalen of de route standhoudt: de adresruimten mogen elkaar niet overlappen, en de netwerkbeveiligingsgroep op het subnet van de resolver moet de clientpool toelaten, wat gewoon nog een bronbereik is. Bewijs het met een effectieve-route-controle vanaf de VM-kant plus één directe query vanaf de client, zodat een zone-probleem, een suffix-probleem of een filter nooit met ontbrekende transit worden verward.