Azure P2S DNS nepavyksta, kai resolver yra susietame VNet

Klientas gali pasiekti savo virtualų tinklą ir vis tiek negeba išspręsti vardų susietame tinkle. Peering nėra gateway tranzitas, kol abi pusės to nepasako.

Pinginkite VM ir ji atsako; paklauskite jos vardo ir klientas sako, kad hostas nežinomas. Kai resolver yra susietame virtualiame tinkle, o ne tame, kuriame yra VPN gateway, ši rezultatų pora yra tikėtina, ir joks resolver diagnostikos kiekis to nepakeis. Trūksta maršrutizavimo sutarties, kurią peering pagal nutylėjimą sulaiko. Dvi topologijos popieriuje atrodo beveik identiškos, o skirtumas tarp veikiančios ir sugedusios yra pora peering jungiklių, nustatytų teisinga kryptimi.

Įsivaizduokite nešiojamąjį kompiuterį, kuris tuneliuoja į gateway VNet2, o DNS aptarnaujantis domeno valdiklis sėdi VNet1.

Dvi topologijos, vienas skirtumas

Įdėkite resolver į paties gateway virtualų tinklą ir vardas išsprendžiamas tą akimirką, kai tunelis pakyla. Jokia peering nuostata tame ieškyme nedalyvauja.

Perkelkite tą patį resolver per peering ir klientas vis dar gauna atsakymą iš VM, o vardas lieka nežinomas. Sertifikatas, tunelis ir klientas nepakitę. Vienintelis dalykas, kuris pasistūmėjo, yra tai, kur gyvena resolver. Peering davė jam maršrutą į tą adresą, o ne gateway įgaliojimą ten nešti srautą.

A pusė: leiskite gateway tranzitą gateway savininkui

Peering sujungia du virtualius tinklus, bet jungtis nėra tranzityvi srautui, kuris ateina per gateway, o point-to-site užklausa ateina būtent taip. Todėl VNet2 gateway neturi pagrindo perduoti paieškos į VNet1, kol dizainas to neleidžia. Leidimas yra jungiklis peering, kuri priklauso tinklui su gateway.

Nustatykite Allow gateway transit VNet2 peering link VNet1. Ši savybė priklauso peering objektui, o ne gateway ištekliui, todėl ją skaitote ir keičiate peering ašmenyje. Tai ir yra visa A pusė.

B pusė: naudokite nuotolinius gateway partnerio pusėje

Kita pusė yra veidrodinis atspindys: VNet1 peering atgal į VNet2 įjunkite Use remote gateways. To paties žymės įjungimas abiejuose galuose arba tik viename palieka pusiau pastatytą kelią ir pirminį simptomą nepaliestą. Tik tinklas su VPN gateway leidžia tranzitą, o partneris yra ta pusė, kuri jį naudoja.

Skaitykite abi savybes abiejuose tinkluose, o ne pasitikėkite portalo ašmeniu, kurį atidarėte paskutinį kartą.

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

Pamatyti porą greta yra greičiausias būdas pagauti apverstą nustatymą. Peering, kuri gateway pusėje praneša AllowGatewayTransit false, paaiškina visą gedimą be paketų fiksavimo.

Ką klientas dar turi gauti

Maršrutizavimas būtinas ir nepakankamas, nes point-to-site profilis taip pat turi duoti klientui DNS adresą, kuris atsako, kai tranzitas veikia. Platformos resolver yra ne tas adresas: jis atsako į su virtualiu tinklu susietas Azure Private DNS zonas, bet nieko apie zoną, talpinamą jūsų pačių katalogo serveriuose, ir būtent tai naudoja šis diegimas. Nukreipkite klientą į jį ir vieši vardai linksmai išsprendžiami, o vidinis hostas lieka nežinomas.

Paklauskite resolver iš prisijungto nešiojamojo kompiuterio, prieš ką nors kitą keisdami.

nslookup dc01.corp.example 10.1.0.4

Skirtasis laikas sako, kad kelio dar trūksta. Autoritetingas atsakymas stumia problemą atgal klientui, dažniausiai priesaga, kuri niekada nepridedama, todėl trumpi vardai keliauja į viešą resolver, kuris linksmai juos sugriauna.

Palyginkite tą pačią sutartį site-to-site pusėje

Niekas iš to nepriklauso būtent nešiojamiesiems kompiuteriams. Pakeiskite klientą į site-to-site filialą ir dvipusis reikalavimas grįžta: filialas atvyksta tiesiai į gateway tinklą, o paslauga už dviejų tinklų vis dar yra už peering.

Tranzitas turi būti suteiktas abiejuose peering, o jungiklis, kuris jį suteikia, gyvena peering, o ne kliento tipe.

Prieš kaltinant gateway

Windows laiko resolver sąrašą kiekvienam adapteriui, todėl patvirtinkite, ką tunelio sąsaja iš tikrųjų gavo, prieš kaltindami gateway.

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

Neigiamas atsakymas išgyvena maršrutizavimo pataisą podėlyje, o pasenęs priesagų sąrašas toliau siunčia užklausas ten, kur zona niekada nebuvo talpinama. Išvalykite, paklauskite dar kartą ir pažymėkite, kuris serveris atsako.

Du mažesni sprendimai nusprendžia, ar kelias išsilaikys: adresų erdvės neturi persidengti, o resolver potinklyje esanti tinklo saugos grupė turi įleisti klientų telkinį, kuris yra tik dar vienas šaltinio diapazonas. Įrodykite tai atlikdami efektyvių maršrutų patikrą iš VM pusės ir vieną tiesioginę užklausą iš kliento, kad zonos problema, priesagos problema ar filtras niekada nebūtų supainioti su trūkstamu tranzitu.

Susiję straipsniai