Azure P2S-DNS feilar når resolveren ligg i eit peera VNet

Ein klient kan nå sitt eige virtuelle nettverk og likevel ikkje løyse namn i eit peera nettverk. Peering er ikkje gateway-transitt før begge sider seier det.

Ping VM-en, og han svarar; spør etter namnet, og klienten seier at verten er ukjend. Når resolveren ligg i eit peera virtuelt nettverk i staden for i det som inneheld VPN-gatewayen, er dette paret med resultat venta, og inga mengd feilsøking av resolveren endrar det. Det som manglar, er ein rutingkontrakt som peering held tilbake som standard. To topologiar ser nesten identiske ut på papiret, og skilnaden mellom verknad og øydelagd er eit par peering-brytarar sette i rett retning.

Sjå føre deg ein berbar PC som tunnelerer inn i ein gateway i VNet2, medan domenekontrolløren som tener DNS sit i VNet1.

To topologiar, éin skilnad

Set resolveren inn i gatewayen sitt eige virtuelle nettverk, og namnet blir løyst i det augneblunken tunnelen kjem opp. Ingen peering-innstilling deltek i det oppslaget.

Flytt den same resolveren over ein peering, og klienten får framleis svar frå VM-en medan namnet blir verande ukjend. Sertifikat, tunnel og klient er uendra. Det einaste som flytta seg, er kvar resolveren bur. Peering gav han ei rute til den adressa, ikkje mynd til at gatewayen ber trafikk dit.

Side A: tillat gateway-transitt hos gatewayen sin eigar

Ein peering knyter saman to virtuelle nettverk, men sambandet er ikkje transitivt for trafikk som kjem gjennom ein gateway, og ein point-to-site-førespurnad kjem nettopp slik. Gatewayen i VNet2 har difor ikkje grunnlag for å overlete oppslaget til VNet1 før designet gir han det. Tillatinga er ein brytar på peeringa som nettverket med gatewayen eig.

Set Allow gateway transit på VNet2 si peering mot VNet1. Eigenskapen høyrer til peering-objektet, ikkje til gateway-ressursen, så du les og endrar han i peering-bladet. Det er heile side A.

Side B: bruk eksterne gatewayar på peer-en

Den andre halvdelen er spegelbiletet: på VNet1 si peering tilbake til VNet2 aktiverer du Use remote gateways. Å slå same flagget på i begge endar, eller berre i den eine, lèt etter ein halvbygd veg og det opphavlege symptomet urørt. Berre nettverket med VPN-gatewayen tillèt transitt, og peer-en er sida som brukar han.

Les båe eigenskapane på båe nettverka i staden for å stole på portalbladet du opna 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

Å sjå paret side om side er den snøggaste måten å fange ei omvend innstilling. Ei peering som rapporterer AllowGatewayTransit false på gateway-sida forklarar heile feilen utan pakkefangst.

Kva klienten framleis må ta imot

Ruting er naudsynt og ikkje tilstrekkeleg, fordi point-to-site-profilen òg må gi klienten ei DNS-adresse som svarar når transitten verkar. Plattformresolveren er ikkje den adressa: han svarar på Azure Private DNS-soner knytte til det virtuelle nettverket, men inkje for ei sone som ligg på dine eigne katalogtenarar, og det er det denne utrullinga brukar. Peik ein klient dit, og offentlege namn blir løyste muntert medan den interne verten blir verande ukjend.

Spør resolveren frå den tilkopla berbare PC-en før du endrar noko anna.

nslookup dc01.corp.example 10.1.0.4

Ein tidsavbrot seier at vegen framleis manglar. Eit autoritativt svar skuvar problemet tilbake til klienten, vanlegvis eit suffiks som aldri blir lagt til, så korte namn reiser til ein offentleg resolver som muntert feilar dei.

Samanlikn den same kontrakten på site-to-site-sida

Ingenting av dette høyrer til berbare PC-ar spesielt. Bytt ut klienten med ein filial på site-to-site, og det tosidige kravet kjem tilbake: filialen kjem direkte til gateway-nettverket, og ei teneste to nettverk unna er framleis bak peeringa.

Transitt må givast på båe peeringane, og brytaren som gir han, bur på peeringa og ikkje på klienttypen.

Før du klandrar gatewayen

Windows held ei resolverliste per adapter, så stadfest kva tunnelgrensesnittet faktisk tok imot før du klandrar gatewayen.

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

Eit negativt svar overlever rutingrettinga i hurtigbufferen, og ei utdatert suffiksliste held fram med å sende spørjingar til ein stad som aldri har hatt sona. Tøm, spør igjen, og noter kva tenar som svarar.

To mindre vilkår avgjer om vegen held: adresseromma må ikkje overlappe, og nettverkssikkerheitsgruppa på subnettet til resolveren må sleppe klientpoolen inn, som berre er nok eit kjeldeområde. Prov det med ein effektiv-rute-sjekk frå VM-sida pluss éi direkte spørjing frå klienten, så eit sone-problem, eit suffiks-problem eller eit filter aldri blir forveksla med manglande transitt.

Relaterte artiklar