Azure P2S DNS ei tööta, kui resolver asub peeritud VNetis

Klient pääseb oma virtuaalvõrku, kuid ei suuda siiski peeritud võrgus nimesid lahendada. Peering ei ole lüüsi transiit enne, kui mõlemad pooled seda ütlevad.

Pingige VM-i ja see vastab; küsige selle nime ja klient ütleb, et host on tundmatu. Kui resolver asub peeritud virtuaalvõrgus, mitte selles, mis sisaldab VPN-i lüüsi, on see tulemuste paar ootuspärane ja ükski resolveri tõrkeotsing ei muuda seda. Puudu on marsruutimisleping, mida peering vaikimisi tagasi hoiab. Kaks topoloogiat näevad paberil peaaegu identsed välja ja vahe töötava ja katkise vahel on paar peeringu lülitit õiges suunas.

Kujutage ette sülearvutit, mis tunnelib VNet2 lüüsile, samal ajal kui DNS-i teenindav domeenikontroller istub VNet1-s.

Kaks topoloogiat, üks erinevus

Pange resolver lüüsi enda virtuaalvõrku ja nimi lahendatakse hetkel, mil tunnel tõuseb. Ükski peeringu seade ei osale selles otsingus.

Viige sama resolver üle peeringu ja klient saab endiselt VM-ilt vastuse, samal ajal kui nimi jääb tundmatuks. Sertifikaat, tunnel ja klient on muutumatud. Ainus, mis liikus, on see, kus resolver elab. Peering andis sellele marsruudi sellele aadressile, mitte lüüsile volituse seal liiklust kanda.

Pool A: lubage lüüsi transiit lüüsi omanikul

Peering ühendab kaks virtuaalvõrku, kuid ühendus ei ole transitiivne lüüsi kaudu saabuva liikluse jaoks ja punkt-koht-ühenduse taotlus saabub täpselt nii. Seetõttu ei ole VNet2 lüüsil õigust otsingut VNet1-le üle anda enne, kui disain seda lubab. Lubadus on lüliti peeringul, mille omanik on lüüsi sisaldav võrk.

Määrake Allow gateway transit VNet2 peeringul VNet1 suunas. Omadus kuulub peeringu objektile, mitte lüüsi ressursile, seega loete ja muudate seda peeringu labas. See on kogu pool A.

Pool B: kasutage partneril kauglüüse

Teine pool on peegelpilt: VNet1 peeringul tagasi VNet2 suunas lubage Use remote gateways. Sama lipu sisselülitamine mõlemas otsas või ainult ühes jätab pooliku tee ja algse sümptomi puutumata. Ainult VPN-i lüüsiga võrk lubab transiiti ja partner on pool, mis seda kasutab.

Lugege mõlemat omadust mõlemas võrgus, selle asemel et usaldada portaalilaba, mille viimati avasite.

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

Paari kõrvuti nägemine on kiireim viis pööratud seade tabamiseks. Peering, mis teatab lüüsi poolel AllowGatewayTransit false, selgitab kogu rikke ilma paketipüügi.

Mida klient peab veel saama

Marsruutimine on vajalik, kuid mitte piisav, sest punkt-koht-profiil peab andma kliendile ka DNS-i aadressi, mis vastab, kui transiit töötab. Platvormi resolver ei ole see aadress: see vastab virtuaalvõrguga seotud Azure Private DNS tsoonidele, kuid mitte teie enda kataloogiserverites majutatud tsoonile, ja seda see juurutus kasutab. Suunake klient sellele ja avalikud nimed lahendatakse rõõmsalt, samal ajal kui sisemine host jääb tundmatuks.

Küsige resolverilt ühendatud sülearvutist enne, kui midagi muud muudate.

nslookup dc01.corp.example 10.1.0.4

Aegumine ütleb, et tee on endiselt puudu. Autoriteetne vastus lükkab probleemi kliendile tagasi, tavaliselt sufiks, mida kunagi ei lisata, nii et lühikesed nimed rändavad avalikku resolverisse, mis need rõõmsalt ebaõnnestub.

Võrrelge sama lepet saidi-ja-saidi poolel

Miski sellest ei kuulu spetsiaalselt sülearvutitele. Vahetage klient saidi-ja-saidi haruga ja kahepoolne nõue naaseb: haru saabub otse lüüsi võrku ja teenus kahe võrgu kaugusel on endiselt peeringu taga.

Transiit tuleb lubada mõlemal peeringul ja lüliti, mis seda lubab, elab peeringul, mitte kliendi tüübil.

Enne kui süüdistate lüüsi

Windows hoiab resolverite loendit iga adapteri kohta, seega kinnitage, mida tunneliliides tegelikult sai, enne kui süüdistate lüüsi.

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

Negatiivne vastus elab vahemälus marsruudiparandusest kauem ja vananenud sufiksiloend saadab jätkuvalt päringuid kohta, kus tsooni kunagi ei majutatud. Tühjendage, küsige uuesti ja märkige, milline server vastab.

Kaks väiksemat tingimust otsustavad, kas tee püsib: aadressiruumid ei tohi kattuda, ja resolveri alamvõrgu võrgu turvagrupp peab lubama kliendi pooli, mis on lihtsalt veel üks allikavahemik. Tõestage seda VM-i poolelt efektiivsete marsruutide kontrolliga pluss ühe otsese päringuga kliendilt, et tsooni probleem, sufiksi probleem või filter ei aetaks kunagi segamini puuduva transiidiga.

Seotud artiklid