Azure P2S-DNS fejler, når resolveren ligger i et peeret VNet

En klient kan nå sit eget virtuelle netværk og alligevel ikke opløse navne i et peeret netværk. Peering er ikke gateway-transit, før begge sider siger det.

Ping VM'en, og den svarer; spørg efter dens navn, og klienten siger, at værten er ukendt. Når resolveren ligger i et peeret virtuelt netværk i stedet for i det, der rummer VPN-gatewayen, er det par af resultater forventeligt, og ingen mængde fejlfinding af resolveren ændrer det. Det, der mangler, er en routingkontrakt, som peering tilbageholder som standard. To topologier ser næsten identiske ud på papiret, og forskellen mellem virkende og brudt er et par peering-kontakter sat i den rigtige retning.

Forestil dig en bærbar computer, der tunnelerer ind i en gateway i VNet2, mens domænecontrolleren, der betjener DNS, sidder i VNet1.

To topologier, én forskel

Sæt resolveren ind i gatewayens eget virtuelle netværk, og navnet opløses i det øjeblik, tunnelen kommer op. Ingen peering-indstilling deltager i den opslag.

Flyt den samme resolver over en peering, og klienten får stadig et svar fra VM'en, mens navnet forbliver ukendt. Certifikat, tunnel og klient er uændrede. Det eneste, der flyttede sig, er, hvor resolveren bor. Peering gav den en rute til den adresse, ikke myndighed til at gatewayen bærer trafik derhen.

Side A: tillad gateway-transit hos gatewayens ejer

En peering forbinder to virtuelle netværk, men forbindelsen er ikke transitiv for trafik, der ankommer gennem en gateway, og en point-to-site-anmodning ankommer netop sådan. Gatewayen i VNet2 har derfor ingen hjemmel til at overgive opslaget til VNet1, før designet giver den det. Tilladelsen er en kontakt på den peering, som netværket med gatewayen ejer.

Sæt Allow gateway transit på VNet2's peering mod VNet1. Egenskaben tilhører peering-objektet, ikke gateway-ressourcen, så du læser og ændrer den på peering-bladet. Det er hele side A.

Side B: brug fjern-gateways på peer'en

Den anden halvdel er spejlbilledet: på VNet1's peering tilbage til VNet2 skal du aktivere Use remote gateways. At slå samme flag til i begge ender, eller kun i den ene, efterlader en halvbygget vej og det oprindelige symptom urørt. Kun netværket med VPN-gatewayen tillader transit, og peer'en er den side, der bruger den.

Læs begge egenskaber på begge netværk i stedet for at stole på det portal-blad, du sidst åbnede.

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

At se parret side om side er den hurtigste måde at fange en omvendt indstilling. En peering, der rapporterer AllowGatewayTransit false på gateway-siden, forklarer hele fejlen uden en pakkefangst.

Hvad klienten stadig skal modtage

Routing er nødvendig og ikke tilstrækkelig, fordi point-to-site-profilen også skal give klienten en DNS-adresse, der svarer, når transit virker. Platformens resolver er ikke den adresse: den svarer på Azure Private DNS-zoner, der er knyttet til det virtuelle netværk, men intet for en zone, der hostes på dine egne domæneservere, og det er hvad denne udrulning bruger. Peg en klient på den, og offentlige navne opløses muntert, mens den interne vært forbliver ukendt.

Forespørg resolveren fra den tilsluttede bærbare computer, før du ændrer noget andet.

nslookup dc01.corp.example 10.1.0.4

En timeout siger, at vejen stadig mangler. Et autoritativt svar skubber problemet tilbage til klienten, normalt et suffiks, der aldrig tilføjes, så korte navne rejser til en offentlig resolver, der muntert afviser dem.

Sammenlign den samme kontrakt på site-to-site-siden

Intet af dette tilhører bærbare computere specielt. Byt klienten ud med en filial på site-to-site, og det tosidede krav vender tilbage: filialen ankommer direkte til gateway-netværket, og en tjeneste to netværk væk er stadig bag peeringen.

Transit skal tillades på begge peeringer, og kontakten, der tillader det, bor på peeringen snarere end på klienttypen.

Før du bebrejder gatewayen

Windows holder en resolverliste pr. adapter, så bekræft, hvad tunnel-interfacet faktisk modtog, før du bebrejder gatewayen.

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

Et negativt svar overlever routing-rettelsen i cachen, og en forældet suffiksliste bliver ved med at sende forespørgsler et sted hen, hvor zonen aldrig har været hostet. Skyl, spørg igen, og noter hvilken server der svarer.

To mindre betingelser afgør, om vejen holder: adresserummene må ikke overlappe, og netværkssikkerhedsgruppen på resolverens undernet skal lukke klientpuljen ind, som blot er endnu et kildeområde. Bevis det med et effektiv-rute-tjek fra VM-siden plus en direkte forespørgsel fra klienten, så et zone-problem, et suffiks-problem eller et filter aldrig forveksles med manglende transit.

Relaterede artikler