Azure P2S-DNS schléit fehl, wann de Resolver an engem gepeerten VNet läit

E Client kann säin eegene virtuelle Reseau erreechen an awer Nimm an engem gepeerten Reseau net opléisen. Peering ass kee Gateway-Transit, bis béid Säiten dat soen.

Ping d'VM an si äntwert; frot no hirem Numm an de Client seet, de Host ass onbekannt. Wann de Resolver an engem gepeerte virtuelle Reseau läit an net an deem, deen de VPN-Gateway enthält, ass dës Puer Resultater ze erwaarden, an egal wéi vill Resolver-Diagnos do dra gestach gëtt, et ännert näischt. Wat feelt, ass en Routing-Kontrakt, deen d'Peering standardmäßeg zeréckhält. Zwou Topologien gesinn op Pabeier bal identesch aus, an den Ënnerscheed tëscht funktionéierend a kaputt ass eng Puer Peering-Schalter, déi an déi richteg Richtung gestallt sinn.

Stellt Iech e Laptop vir, deen an e Gateway am VNet2 tunnelt, wärend den Domänen-Controller, deen DNS servéiert, am VNet1 sëtzt.

Zwou Topologien, een Ënnerscheed

Setzt de Resolver an den eegene virtuelle Reseau vum Gateway an den Numm léist sech de Moment op, wou den Tunnel eropkënnt. Keng Peering-Astellung hëlt un där Sich deel.

Verreet de selwechte Resolver iwwer eng Peering an de Client kritt nach ëmmer eng Äntwert vun der VM, wärend den Numm onbekannt bleift. Zertifikat, Tunnel a Client sinn onverännert. Dat eenzegt, wat sech beweegt huet, ass wou de Resolver wunnt. D'Peering huet him eng Route op déi Adress ginn, net dem Gateway d'Autoritéit, Trafik dohin ze droen.

Säit A: erlaabt de Gateway-Transit beim Gateway-Eegentmer

Eng Peering verbënnt zwee virtuell Reseauen, awer d'Verbindung ass net transitiv fir Trafik, dee duerch e Gateway kënnt, an eng Point-to-Site-Ufro kënnt genee esou. Den Gateway am VNet2 huet dofir keng Basis, d'Sich un den VNet1 weiderzeginn, bis den Design et erlaabt. D'Erlabnes ass e Schalter op der Peering, dee vum Reseau gehéiert, deen de Gateway enthält.

Setzt Allow gateway transit op der Peering vum VNet2 a Richtung VNet1. D'Eegenschaft gehéiert zum Peering-Objet, net zu der Gateway-Ressource, dofir liest an ännert een se am Peering-Blade. Dat ass déi ganz Säit A.

Säit B: benotzt distante Gateways um Peer

Déi aner Halschent ass d'Spigelbild: op der Peering vum VNet1 zréck op VNet2 aktivéiert Use remote gateways. Dee selwechte Fändel op béiden Enner, oder just op engem, unzemaachen, hannerléisst en hallef gebaute Wee an dat ursprénglecht Symptom onberéiert. Nëmmen de Reseau mam VPN-Gateway erlaabt Transit, an de Peer ass déi Säit, déi en benotzt.

Liest béid Eegenschaften op béide Reseauen, amplaz dem Portal-Blade ze vertrauen, deen Dir fir d'lescht opgemaach hutt.

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

D'Puer niewenteneen ze gesinn ass de séierste Wee, eng ëmgedréit Astellung ze fannen. Eng Peering, déi op der Gateway-Säit AllowGatewayTransit false mellt, erkläert de ganzen Ausfall ouni Paketopnam.

Wat de Client nach ëmmer kréie muss

Routing ass noutwendeg an net duergend, well de Point-to-Site-Profil dem Client och eng DNS-Adress muss ginn, déi äntwert, wann den Transit funktionéiert. De Plattform-Resolveur ass déi Adress net: hien äntwert op Azure Private DNS-Zonen, déi mam virtuelle Reseau verbonne sinn, awer näischt fir eng Zon, déi op Ären eegene Verzeechniss-Server gehost gëtt, an dat ass wat dës Deployement benotzt. Riicht e Client dohin a Public Nimm léisen sech frou op, wärend den internen Host onbekannt bleift.

Frot de Resolver vum verbonnenen Laptop aus, ier Dir eppes anescht ännert.

nslookup dc01.corp.example 10.1.0.4

En Timeout seet, datt de Wee nach feelt. Eng autoritativ Äntwert dréckt de Problem zréck op de Client, meeschtens e Suffix, deen ni ugehaange gëtt, dofir reese kuerz Nimm zu engem ëffentleche Resolver, dee se frou versoe léisst.

Vergläicht deen selwechte Kontrakt op der Site-to-Site-Säit

Näischt dovun ass speziell fir Laptops. Tauscht de Client géint eng Filial op Site-to-Site aus an d'zwee-säiteg Fuerderung kënnt zréck: d'Filial kënnt direkt an de Gateway-Reseau, an e Service zwee Reseauen ewech ass nach ëmmer hannert der Peering.

Den Transit muss op béide Peeringen erlaabt ginn, an de Schalter, deen en erlaabt, läit op der Peering an net op dem Client-Typ.

Ier Dir de Gateway beschëllegt

Windows hält eng Resolver-Lëscht pro Adapter, dofir bestätegt, wat den Tunnel-Interface tatsächlech kritt huet, ier Dir de Gateway beschëllegt.

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

Eng negativ Äntwert iwwerlieft d'Routing-Korrektur am Cache, an eng verstëmmt Suffix-Lëscht schéckt weider Ufroen dohin, wou d'Zon ni gehost gouf. Leert, frot nach eng Kéier, a notéiert, wéi e Server äntwert.

Zwou méi kleng Bedingungen entscheeden, ob de Wee hält: d'Adressraim dierfe sech net iwwerlappen, an d'Netzwierksécherheetsgrupp um Resolver sengem Subnet muss de Client-Pool eralaassen, deen just nach eng aner Quell-Range ass. Beweist et mat enger Effektiv-Route-Prüfung vun der VM-Säit plus enger direkter Ufro vum Client, sou datt e Zonen-Problem, e Suffix-Problem oder e Filter ni mat feelendem Transit verwiesselt gëtt.

Ähnlech Artikelen