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

En klient kan nå sitt eget virtuelle nettverk og likevel ikke slå opp navn i et peeret nettverk. Peering er ikke gateway-transitt før begge sider sier det.

Ping VM-en, og den svarer; spør etter navnet, og klienten sier at verten er ukjent. Når resolveren ligger i et peeret virtuelt nettverk i stedet for i det som inneholder VPN-gatewayen, er det paret med resultater forventet, og ingen mengde feilsøking av resolveren endrer det. Det som mangler, er en rutingkontrakt som peering holder tilbake som standard. To topologier ser nesten identiske ut på papiret, og forskjellen mellom virkende og ødelagt er et par peering-brytere satt i riktig retning.

Se for deg en bærbar PC som tunnelerer inn i en gateway i VNet2, mens domenekontrolleren som betjener DNS sitter i VNet1.

To topologier, én forskjell

Sett resolveren inn i gatewayens eget virtuelle nettverk, og navnet løses i det øyeblikket tunnelen kommer opp. Ingen peering-innstilling deltar i det oppslaget.

Flytt den samme resolveren over en peering, og klienten får fortsatt svar fra VM-en mens navnet forblir ukjent. Sertifikat, tunnel og klient er uendret. Det eneste som flyttet seg, er hvor resolveren bor. Peering ga den en rute til den adressen, ikke myndighet til at gatewayen bærer trafikk dit.

Side A: tillat gateway-transitt hos gatewayens eier

En peering forbinder to virtuelle nettverk, men forbindelsen er ikke transitiv for trafikk som kommer gjennom en gateway, og en point-to-site-forespørsel kommer nettopp slik. Gatewayen i VNet2 har derfor ikke grunnlag for å overlate oppslaget til VNet1 før designet gir den det. Tillatelsen er en bryter på peeringen som nettverket med gatewayen eier.

Sett Allow gateway transit på VNet2s peering mot VNet1. Egenskapen tilhører peering-objektet, ikke gateway-ressursen, så du leser og endrer den i peering-bladet. Det er hele side A.

Side B: bruk eksterne gatewayer på peer-en

Den andre halvdelen er speilbildet: på VNet1s peering tilbake til VNet2 aktiverer du Use remote gateways. Å slå samme flagg på i begge ender, eller bare i den ene, etterlater en halvbygd vei og det opprinnelige symptomet urørt. Bare nettverket med VPN-gatewayen tillater transitt, og peer-en er siden som bruker den.

Les begge egenskapene på begge nettverkene i stedet for å stole på portalbladet du åpnet 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

Å se paret side om side er den raskeste måten å fange en omvendt innstilling. En peering som rapporterer AllowGatewayTransit false på gateway-siden forklarer hele feilen uten pakkefangst.

Hva klienten fortsatt må motta

Ruting er nødvendig og ikke tilstrekkelig, fordi point-to-site-profilen også må gi klienten en DNS-adresse som svarer når transitten virker. Plattformresolveren er ikke den adressen: den svarer på Azure Private DNS-soner knyttet til det virtuelle nettverket, men ingenting for en sone som ligger på dine egne katalogservere, og det er det denne utrullingen bruker. Pek en klient dit, og offentlige navn løses muntert mens den interne verten forblir ukjent.

Spør resolveren fra den tilkoblede bærbare PC-en før du endrer noe annet.

nslookup dc01.corp.example 10.1.0.4

En tidsavbrudd sier at veien fortsatt mangler. Et autoritativt svar skyver problemet tilbake til klienten, vanligvis et suffiks som aldri legges til, så korte navn reiser til en offentlig resolver som muntert feiler dem.

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

Ingenting av dette tilhører bærbare PC-er spesielt. Bytt ut klienten med en filial på site-to-site, og det tosidige kravet kommer tilbake: filialen ankommer direkte til gateway-nettverket, og en tjeneste to nettverk unna er fortsatt bak peeringen.

Transitt må gis på begge peeringene, og bryteren som gir den, bor på peeringen og ikke på klienttypen.

Før du klandrer gatewayen

Windows holder en resolverliste per adapter, så bekreft hva tunnelgrensesnittet faktisk mottok før du klandrer gatewayen.

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

Et negativt svar overlever rutingrettelsen i hurtigbufferen, og en utdatert suffiksliste fortsetter å sende spørringer til et sted som aldri har hatt sonen. Tøm, spør igjen, og noter hvilken server som svarer.

To mindre betingelser avgjør om veien holder: adresserommene må ikke overlappe, og nettverkssikkerhetsgruppen på resolverens subnett må slippe klientpoolen inn, som bare er nok et kildeområde. Bevis det med en effektiv-rute-sjekk fra VM-siden pluss én direkte spørring fra klienten, så et sone-problem, et suffiks-problem eller et filter aldri forveksles med manglende transitt.

Relaterte artikler