Azure P2S DNS bregst þegar resolver er í paraðri VNet

Skjólstæðingur getur náð eigin sýndarneti og samt mistekist að leysa nöfn í paraðri neti. Pörun er ekki gáttarflutningur fyrr en báðir aðilar segja það.

Pingaðu VM og hún svarar; spurðu að nafni hennar og skjólstæðingurinn segir að hýsillinn sé óþekktur. Þegar resolver er í paraðri sýndarneti í stað þess sem geymir VPN-gáttina eru þessi tvö svör væntanleg, og engin magn af villuleit resolver breytir því. Það sem vantar er leiðarvalssamningur sem pörun heldur eftir sjálfgefið. Tvær staðfræði líta næstum eins út á pappír, og bilið milli virks og bilaðs er par af pörunarrofar stillt í rétta átt.

Ímyndaðu þér fartölvu sem tunnlar í gátt í VNet2, á meðan lénsstjórinn sem þjónar DNS situr í VNet1.

Tvö staðfræði, einn munur

Setja resolver inni í eigin sýndarnet gáttarinnar og nafnið leysist um leið og tunnillinn rís. Engin pörunarstilling tekur þátt í þeirri uppflettingu.

Færðu sama resolver yfir pörun og skjólstæðingurinn fær enn svar frá VM á meðan nafnið er óþekkt. Vottorð, tunnill og skjólstæðingur eru óbreytt. Það eina sem færðist er hvar resolver býr. Pörunin gaf honum leið að þeirri vist, ekki heimild fyrir gáttina til að bera umferð þangað.

Hlið A: heimilaðu gáttarflutning hjá eiganda gáttarinnar

Pörun tengir tvö sýndarnet, en tengingin er ekki gegnumstreymis fyrir umferð sem kemur í gegnum gátt, og beiðni punkt-til-staðar kemur einmitt þannig. Gáttin í VNet2 hefur því ekki heimild til að afhenda uppflettinguna til VNet1 fyrr en hönnunin leyfir það. Leyfið er rofi á pöruninni sem netið með gáttinni á.

Stilltu Allow gateway transit á pörun VNet2 í átt að VNet1. Eiginleikinn tilheyrir pörunarhlutnum, ekki gáttarauðlindinni, svo þú lest og breytir honum í pörunarblaðinu. Það er öll hlið A.

Hlið B: notaðu fjarlægar gáttir á jafningjanum

Hinn helmingurinn er spegilmynd: á pörun VNet1 aftur í VNet2 skaltu virkja Use remote gateways. Að kveikja á sama fána á báðum endum, eða aðeins öðrum, skilur eftir hálfbyggða leið og upprunaleg einkenni ósnortin. Aðeins netið með VPN-gáttina heimilar flutning, og jafninginn er sú hlið sem notar hann.

Lestu báða eiginleika á báðum netum í stað þess að treysta gáttarblaðinu sem þú opnaðir síðast.

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

Að sjá parið hlið við hlið er fljótlegasta leiðin til að grípa öfuga stillingu. Pörun sem tilkynnir AllowGatewayTransit false á gáttarhlið útskýrir alla bilunina án pakkaskráningar.

Hvað skjólstæðingurinn verður samt að fá

Leiðarval er nauðsynlegt og ekki nægjanlegt, því punkt-til-staðar-sniðið verður líka að gefa skjólstæðingnum DNS-vist sem svarar þegar flutningurinn virkar. Resolver kerfisins er ekki þessi vist: hann svarar fyrir Azure Private DNS svæði sem tengjast sýndarnetinu, en ekkert fyrir svæði sem er hýst á þínum eigin skráarþjónum, og það er það sem þessi uppsetning notar. Beindu skjólstæðingi að honum og opinber nöfn leysast glatt á meðan innri hýsillinn er áfram óþekktur.

Spurðu resolver frá tengdu fartölvunni áður en þú breytir nokkru öðru.

nslookup dc01.corp.example 10.1.0.4

Tímamörk segja að leiðin vanti enn. Valdlegt svar ýtir vandamálinu aftur til skjólstæðingsins, venjulega viðskeyti sem er aldrei bætt við, svo stutt nöfn ferðast til opinbers resolver sem mistekst þau glatt.

Berðu sama samning saman á stað-til-staðar hliðinni

Ekkert af þessu tilheyrir fartölvum sérstaklega. Skiptu skjólstæðingnum út fyrir útibú á stað-til-stað og krafan um tvær hliðir kemur aftur: útibúið kemur beint í gáttarnetið, og þjónusta tvö net í burtu er enn bak við pörunina.

Veita verður flutning á báðum pörunum, og rofinn sem veitir hann býr á pöruninni frekar en á skjólstæðingstegundinni.

Áður en þú kennir gáttinni um

Windows heldur resolver-lista fyrir hverja millistykki, svo staðfestu hvað tunnilviðmótið fékk í raun áður en þú kennir gáttinni um.

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

Neikvætt svar lifir lengur í skyndiminni en leiðarvalslagfæringin, og úreltur viðskeytalisti heldur áfram að senda fyrirspurnir þangað sem svæðið var aldrei hýst. Hreinsaðu, spurðu aftur og skráðu hvaða þjónn svarar.

Tvö minni skilyrði ráða því hvort leiðin heldur: vistrýmin mega ekki skarast, og netöryggishópurinn á undirneti resolver verður að hleypa skjólstæðingasafninu inn, sem er bara annað upprunasvið. Sannaðu það með skoðun á virkum leiðum frá VM-hlið auk einnar beinnar fyrirspurnar frá skjólstæðingnum, svo svæðisvandamál, viðskeytavandamál eða sía verði aldrei mistalin sem flutningur sem vantar.

Tengdir greinar