Azure P2S-DNS mislearret as de resolver yn in peard VNet sits

In klant kin syn eigen firtuele netwurk berikke en dochs namen yn in peard netwurk net oplosse. Peering is gjin gateway-transyt oant beide kanten dat sizze.

Ping de VM en hy antwurdet; freegje syn namme en de klant seit dat de host ûnbekend is. As de resolver yn in peard firtueel netwurk sit yn stee fan yn it netwurk dat de VPN-gateway befettet, is dat pear resultaten te ferwachtsjen, en gjin hoemannichte resolver-diagnoaze feroaret dat. Wat mist is in rûteskontrakt dat peering standert efterhâldt. Twa topologyen lykje op papier hast itselde, en it gat tusken wurkjen en stikken is in pear peering-skeakels yn de goede rjochting set.

Stel jo in laptop foar dy't yn in gateway yn VNet2 tunnellet, wylst de domeincontroller dy't DNS tsjinnet yn VNet1 sit.

Twa topologyen, ien ferskil

Set de resolver yn it eigen firtuele netwurk fan de gateway en de namme wurdt oplost op it momint dat de tunnel omheech komt. Gjin peering-ynstelling docht oan dy syktocht mei.

Ferpleats deselde resolver oer in peering en de klant kriget noch altyd in antwurd fan de VM wylst de namme ûnbekend bliuwt. Sertifikaat, tunnel en klant binne net feroare. It iennige dat ferpleatst is, is wêr't de resolver wennet. Peering joech him in rûte nei dat adres, net it foech oan de gateway om dêr ferkear te dragen.

Kant A: tastean gateway-transyt by de gateway-eigner

In peering ferbynt twa firtuele netwurken, mar de ferbining is net transityf foar ferkear dat troch in gateway komt, en in punt-nei-site-oanfraach komt krekt sa. De gateway yn VNet2 hat dêrom gjin foech om de syktocht oan VNet1 oer te jaan oant it ûntwerp dat tastiet. De tastimming is in skeakel op de peering dy't eigendom is fan it netwurk dat de gateway befettet.

Set Allow gateway transit op de peering fan VNet2 nei VNet1. De eigenskip heart by it peering-objekt, net by de gateway-boarne, dus jo lêze en feroarje him yn it peering-blêd. Dat is hiel kant A.

Kant B: brûk fiere gateways op de peir

De oare helte is it spegelbyld: op de peering fan VNet1 werom nei VNet2, skeakelje Use remote gateways oan. Deselde flagge oan beide einen, of allinnich oan ien, lit in heal-boud paad en it oarspronklike symptoom ûnoantaast. Allinnich it netwurk mei de VPN-gateway lit transyt ta, en de peir is de kant dy't him brûkt.

Lês beide eigenskippen op beide netwurken yn stee fan it portaalblêd te fertrouwen dat jo it lêst iepene.

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

It pear neist elkoar sjen is de fluchste manier om in omkearde ynstelling te fangen. In peering dy't AllowGatewayTransit false oan de gateway-kant rapportearret, ferklearret de hiele mislearring sûnder pakketfangst.

Wat de klant noch krije moat

Rûtering is nedich en net genôch, want it punt-nei-site-profyl moat de klant ek in DNS-adres jaan dat antwurdet sadree't transyt wurket. De resolver fan it platfoarm is dat adres net: hy antwurdet foar Azure Private DNS-sônes dy't oan it firtuele netwurk keppele binne, mar neat foar in sône dy't op jo eigen mapsservers host wurdt, en dat is wat dizze útrulling brûkt. Wiis in klant dêrop en iepenbiere namen wurde fleurich oplost wylst de ynterne host ûnbekend bliuwt.

Freegje de resolver út fan de ferbûne laptop foardat jo eat oars feroarje.

nslookup dc01.corp.example 10.1.0.4

In time-out seit dat it paad noch mist. In autoritatyf antwurd skoot it probleem werom nei de klant, meast in efterheaksel dat nea taheakke wurdt, sadat koarte namen reizgje nei in iepenbiere resolver dy't se fleurich mislearje lit.

Fergelykje itselde kontrakt oan de site-nei-site-kant

Neat hjirfan heart spesifyk by laptops. Ferwikselje de klant foar in filiaal by site-nei-site en de twasidige eask komt werom: it filiaal komt streekrjocht yn it gateway-netwurk, en in tsjinst twa netwurken fuort is noch altyd efter de peering.

Transyt moat by beide peerings ferliend wurde, en de skeakel dy't dat docht wennet op de peering yn stee fan op it klanttype.

Foardat jo de gateway de skuld jouwe

Windows hâldt in resolverlist per adapter, dus befêstigje wat de tunnel-ynterface wirklik krigen hat foardat jo de gateway de skuld jouwe.

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

In negatyf antwurd oerlibbet de rûteringsreparaasje yn de cache, en in ferâldere efterheaksel-list stjoert fragen troch nei in plak dat de sône nea host hat. Wiskje, freegje opnij, en notearje hokker tsjinner antwurdet.

Twa lytsere betingsten beslisse oft it paad hâldt: de adresromten meie net oerlaapje, en de netwurkfeiligensgroep op it subnet fan de resolver moat de klantpool talitte, dat is gewoan noch in boarnerige. Bewiis it mei in effektive-rûte-kontrôle fan de VM-kant plus ien direkte fraach fan de klant, sadat in sône-probleem, in efterheaksel-probleem of in filter nea foar ûntbrekkend transyt oansjoen wurdt.

Relatearre artikelen