Azure P2S-DNS misslyckas när resolveraren ligger i ett peerat VNet

En klient kan nå sitt eget virtuella nätverk och ändå inte lösa namn i ett peerat nätverk. Peering är inte gateway-transit förrän båda sidor säger det.

Pinga VM:en och den svarar; fråga efter dess namn och klienten säger att värden är okänd. När resolveraren ligger i ett peerat virtuellt nätverk i stället för i det som innehåller VPN-gatewayen är det paret resultat väntat, och ingen mängd felsökning av resolveraren ändrar det. Det som saknas är ett routingavtal som peering håller tillbaka som standard. Två topologier ser nästan identiska ut på papperet, och skillnaden mellan fungerande och trasig är ett par peering-brytare satta i rätt riktning.

Föreställ dig en bärbar dator som tunnlar in i en gateway i VNet2, medan domänkontrollanten som betjänar DNS sitter i VNet1.

Två topologier, en skillnad

Sätt resolveraren i gatewayens eget virtuella nätverk och namnet löses i samma ögonblick som tunneln kommer upp. Ingen peering-inställning deltar i den uppslagningen.

Flytta samma resolverare över en peering och klienten får fortfarande svar från VM:en medan namnet förblir okänt. Certifikat, tunnel och klient är oförändrade. Det enda som flyttade sig är var resolveraren bor. Peeringen gav den en väg till den adressen, inte befogenhet åt gatewayen att bära trafik dit.

Sida A: tillåt gateway-transit hos gatewayens ägare

En peering förenar två virtuella nätverk, men föreningen är inte transitiv för trafik som kommer in genom en gateway, och en point-to-site-begäran kommer precis så. Gatewayen i VNet2 har därför inget mandat att lämna över uppslagningen till VNet1 förrän designen ger den det. Tillståndet är en brytare på peeringen som ägs av nätverket med gatewayen.

Ställ in Allow gateway transit på VNet2:s peering mot VNet1. Egenskapen tillhör peering-objektet, inte gateway-resursen, så du läser och ändrar den i peering-bladet. Det är hela sida A.

Sida B: använd fjärrgatewayer på peer-partnern

Den andra halvan är spegelbilden: på VNet1:s peering tillbaka till VNet2 aktiverar du Use remote gateways. Att slå på samma flagga i båda ändar, eller bara i en, lämnar en halvbyggd väg och det ursprungliga symptomet orört. Bara nätverket med VPN-gatewayen tillåter transit, och peern är den sida som använder den.

Läs båda egenskaperna på båda nätverken i stället för att lita på portalbladet du öppnade sist.

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

Att se paret sida vid sida är det snabbaste sättet att fånga en omvänd inställning. En peering som rapporterar AllowGatewayTransit false på gateway-sidan förklarar hela felet utan paketfångst.

Vad klienten fortfarande måste få

Routing är nödvändig och inte tillräcklig, eftersom point-to-site-profilen också måste ge klienten en DNS-adress som svarar när transiten fungerar. Plattformens resolverare är inte den adressen: den svarar för Azure Private DNS-zoner kopplade till det virtuella nätverket, men inget för en zon som ligger på dina egna katalogservrar, och det är vad den här distributionen använder. Peka en klient dit och offentliga namn löses glatt medan den interna värden förblir okänd.

Fråga resolveraren från den anslutna bärbara datorn innan du ändrar något annat.

nslookup dc01.corp.example 10.1.0.4

En timeout säger att vägen fortfarande saknas. Ett auktoritativt svar skjuter tillbaka problemet till klienten, oftast ett suffix som aldrig läggs till, så korta namn reser till en offentlig resolverare som glatt får dem att misslyckas.

Jämför samma avtal på site-to-site-sidan

Inget av detta hör särskilt till bärbara datorer. Byt ut klienten mot en filial på site-to-site och det tvåsidiga kravet kommer tillbaka: filialen anländer direkt till gateway-nätverket, och en tjänst två nätverk bort ligger fortfarande bakom peeringen.

Transit måste beviljas på båda peeringarna, och brytaren som beviljar den sitter på peeringen och inte på klienttypen.

Innan du skyller på gatewayen

Windows håller en resolverlista per adapter, så bekräfta vad tunnelgränssnittet faktiskt fick innan du skyller på gatewayen.

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

Ett negativt svar överlever routingrättelsen i cachen, och en inaktuell suffixlista fortsätter skicka frågor till en plats som aldrig har varit värd för zonen. Töm, fråga igen och notera vilken server som svarar.

Två mindre villkor avgör om vägen håller: adressrymderna får inte överlappa, och nätverkssäkerhetsgruppen på resolverarens undernät måste släppa in klientpoolen, som bara är ännu ett källområde. Bevisa det med en effektiv-rutt-kontroll från VM-sidan plus en direkt fråga från klienten, så att ett zonproblem, ett suffixproblem eller ett filter aldrig förväxlas med saknad transit.

Relaterade artiklar