Azure P2S DNS malsukcesas kiam la solvilo estas en kunligita VNet

Kliento povas atingi sian propran virtualan reton kaj tamen malsukcesi solvi nomojn en kunligita reto. Kunligo ne estas paseja transiro ĝis ambaŭ flankoj konsentas.

Pingu la VM-on kaj ĝi respondas; demandu ĝian nomon kaj la kliento diras, ke la gastiganto estas nekonata. Kiam la solvilo sidas en kunligita virtuala reto anstataŭ en tiu, kiu enhavas la VPN-pasejon, tiu paro da rezultoj estas atendebla, kaj nenia kvanto da solvila diagnozado ŝanĝas tion. Mankas enkursiga kontrakto, kiun kunligo retenas defaŭlte. Du topologioj aspektas preskaŭ identaj surpapere, kaj la diferenco inter funkcianta kaj rompita estas paro da kunligaj ŝaltiloj metitaj en la ĝustan direkton.

Imagu tekkomputilon tunelantan en pasejon en VNet2, dum la domajna regilo, kiu servas DNS, sidas en VNet1.

Du topologioj, unu diferenco

Metu la solvilon en la propran virtualan reton de la pasejo kaj la nomo solviĝas en la momento, kiam la tunelo leviĝas. Neniu kunliga agordo partoprenas en tiu serĉo.

Transloku la saman solvilon trans kunligon kaj la kliento ankoraŭ ricevas respondon de la VM, dum la nomo restas nekonata. Atestilo, tunelo kaj kliento neŝanĝitaj. La sola afero, kiu moviĝis, estas kie loĝas la solvilo. Kunligo donis al ĝi itineron al tiu adreso, ne rajtigon por la pasejo porti trafikon tien.

Flanko A: permesu pasejan transiron ĉe la paseja posedanto

Kunligo kunigas du virtualajn retojn, sed la kuniĝo ne estas transira por trafiko, kiu alvenas tra pasejo, kaj peto de punkto-al-ejo alvenas ĝuste tiel. La pasejo en VNet2 do ne rajtas transdoni la serĉon al VNet1, ĝis la dezajno tion permesas. La permeso estas ŝaltilo sur la kunligo posedata de la reto, kiu tenas la pasejon.

Agordu Allow gateway transit sur la kunligo de VNet2 al VNet1. La eco apartenas al la kunliga objekto, ne al la paseja rimedo, do vi legas kaj ŝanĝas ĝin en la kunliga panelo. Tio estas la tuta flanko A.

Flanko B: uzu malproksimajn pasejojn ĉe la kunulo

La alia duono estas la spegula bildo: sur la kunligo de VNet1 reen al VNet2, ŝaltu Use remote gateways. Ŝalti la saman flagon ĉe ambaŭ finoj, aŭ nur ĉe unu, lasas duonkonstruitan vojon kaj la originan simptomon netuŝitaj. Nur la reto kun la VPN-pasejo permesas transiron, kaj la kunulo estas la flanko, kiu ĝin uzas.

Legu ambaŭ ecojn sur ambaŭ retoj anstataŭ fidi la portalpanelo, kiun vi laste malfermis.

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

Vidi la paron unu apud la alia estas la plej rapida maniero kapti inversigitan agordon. Kunligo, kiu raportas AllowGatewayTransit false ĉe la paseja flanko, klarigas la tutan fiaskon sen paketa kaptado.

Kion la kliento ankoraŭ devas ricevi

Enkursigado estas necesa kaj ne sufiĉa, ĉar la profilo punkto-al-ejo ankaŭ devas doni al la kliento DNS-adreson, kiu respondas post kiam la transiro funkcias. La platforma solvilo ne estas tiu adreso: ĝi respondas pri zonoj Azure Private DNS ligitaj al la virtuala reto, sed nenion pri zono gastigata sur viaj propraj dosierujaj serviloj, kaj tion uzas ĉi tiu deplojo. Direktu klienton al ĝi kaj publikaj nomoj solviĝas gaje, dum la interna gastiganto restas nekonata.

Demandu la solvilon de la konektita tekkomputilo antaŭ ol ŝanĝi ion alian.

nslookup dc01.corp.example 10.1.0.4

Tempolimo diras, ke la vojo ankoraŭ mankas. Aŭtoritata respondo puŝas la problemon reen al la kliento, kutime sufikso, kiu neniam aldoniĝas, do mallongaj nomoj vojaĝas al publika solvilo, kiu gaje malsukcesigas ilin.

Komparu la saman kontrakton ĉe la flanko ejo-al-ejo

Nenio el tio apartenas specife al tekkomputiloj. Anstataŭigu la klienton per filio ĉe ejo-al-ejo kaj la duflanka postulo revenas: la filio alvenas rekte al la paseja reto, kaj servo du retojn for estas ankoraŭ malantaŭ la kunligo.

Transiro devas esti permesita ĉe ambaŭ kunligoj, kaj la ŝaltilo, kiu ĝin permesas, loĝas sur la kunligo anstataŭ sur la klienta tipo.

Antaŭ ol vi kulpigas la pasejon

Windows tenas solvilan liston por adaptilo, do konfirmu, kion la tunela interfaco efektive ricevis, antaŭ ol kulpigi la pasejon.

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

Negativa respondo postvivas la enkursigan riparon en la kaŝmemoro, kaj kaduka sufiksa listo daŭre sendas petojn al loko, kiu neniam gastigis la zonon. Malplenigu, demandu denove, kaj notu, kiu servilo respondas.

Du pli malgrandaj kondiĉoj decidas, ĉu la vojo teniĝas: la adresaj spacoj ne rajtas interkovriĝi, kaj la reta sekureca grupo sur la subreto de la solvilo devas akcepti la klientan naĝejon, kiu estas simple alia fonta gamo. Pruvu tion per kontrolo de efektiva itinero de la VM-flanko plus unu rekta demando de la kliento, por ke zona problemo, sufiksa problemo aŭ filtrilo neniam estu konfuzitaj kun mankanta transiro.

Rilataj artikoloj