Nabibigo ang Azure P2S DNS kapag ang resolver ay nasa peered na VNet

I-ping ang VM at sumasagot ito; tanungin ang pangalan nito at sinasabi ng kliyente na hindi kilala ang host. Kapag ang resolver ay nasa peered na virtual network sa halip na sa network na may VPN gateway, inaasahan ang pares ng resultang iyon, at walang dami ng troubleshooting ng resolver ang makakapagbago nito. Ang kulang ay isang kontrata sa routing na hinahawakan ng peering bilang default. Dalawang topology ang halos magkapareho sa papel, at ang agwat sa pagitan ng gumagana at sira ay isang pares ng peering switch na nakatutok sa tamang direksyon.

Isipin ang isang laptop na nagtu-tunnel sa isang gateway sa VNet2, habang ang domain controller na naghahatid ng DNS ay nakaupo sa VNet1.

Dalawang topology, isang pagkakaiba

Ilagay ang resolver sa loob ng sariling virtual network ng gateway at malulutas ang pangalan sa sandaling umangat ang tunnel. Walang setting ng peering ang lumalahok sa paghahanap na iyon.

Ilipat ang parehong resolver sa kabilang panig ng peering at nakakakuha pa rin ng sagot ang kliyente mula sa VM habang nananatiling hindi kilala ang pangalan. Hindi nagbago ang sertipiko, tunnel at kliyente. Ang tanging gumalaw ay kung saan nakatira ang resolver. Binigyan ito ng peering ng ruta patungo sa address na iyon, hindi awtoridad sa gateway na magdala ng trapiko doon.

Gilid A: payagan ang gateway transit sa may-ari ng gateway

Pinagsasama ng peering ang dalawang virtual network, ngunit ang pagsasama ay hindi transitibo para sa trapikong dumarating sa pamamagitan ng gateway, at ang point-to-site na kahilingan ay dumarating nang eksaktong ganoon. Kaya ang gateway sa VNet2 ay walang batayan na ibigay ang paghahanap sa VNet1 hanggang payagan ito ng disenyo. Ang pahintulot ay isang switch sa peering na pag-aari ng network na may gateway.

Itakda ang Allow gateway transit sa peering ng VNet2 patungong VNet1. Ang property ay pag-aari ng peering object, hindi ng gateway resource, kaya binabasa at binabago ito sa peering blade. Iyon ang buong gilid A.

Gilid B: gumamit ng malalayong gateway sa kapareha

Ang kabilang kalahati ay ang salamin na larawan: sa peering ng VNet1 pabalik sa VNet2, i-enable ang Use remote gateways. Ang pagbukas ng parehong flag sa dalawang dulo, o sa isa lamang, ay nag-iiwan ng kalahating itinayong landas at hindi nagagalaw ang orihinal na sintomas. Tanging ang network na may VPN gateway ang pumapayag ng transit, at ang kapareha ang panig na gumagamit nito.

Basahin ang parehong property sa dalawang network sa halip na magtiwala sa portal blade na huling binuksan.

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

Ang makita ang pares nang magkatabi ay ang pinakamabilis na paraan upang mahuli ang baligtad na setting. Ang peering na nag-uulat ng AllowGatewayTransit false sa gilid ng gateway ay nagpapaliwanag ng buong kabiguan nang walang packet capture.

Ano ang dapat pa ring matanggap ng kliyente

Kailangan ang routing at hindi sapat, dahil ang point-to-site profile ay dapat ding magbigay sa kliyente ng DNS address na sumasagot kapag gumana ang transit. Ang resolver ng platform ay hindi ang address na iyon: sinasagot nito ang mga Azure Private DNS zone na naka-link sa virtual network, ngunit wala para sa zone na naka-host sa sarili mong mga directory server, at iyon ang ginagamit ng deployment na ito. Ituro ang isang kliyente doon at masayang malulutas ang mga pampublikong pangalan habang nananatiling hindi kilala ang panloob na host.

Tanungin ang resolver mula sa konektadong laptop bago baguhin ang anumang iba pa.

nslookup dc01.corp.example 10.1.0.4

Sinasabi ng timeout na kulang pa ang landas. Itinutulak ng awtoritatibong sagot ang problema pabalik sa kliyente, kadalasan ay isang suffix na hindi kailanman idinadagdag, kaya ang maiikling pangalan ay naglalakbay sa isang pampublikong resolver na masayang binibigo sila.

Ihambing ang parehong kontrata sa gilid ng site-to-site

Wala sa mga ito ang partikular na pag-aari ng mga laptop. Palitan ang kliyente ng sangay sa site-to-site at bumalik ang dalawang-panig na pangangailangan: ang sangay ay dumarating nang direkta sa network ng gateway, at ang serbisyo na dalawang network ang layo ay nasa likod pa rin ng peering.

Ang transit ay dapat ibigay sa dalawang peering, at ang switch na nagbibigay nito ay nasa peering at hindi sa uri ng kliyente.

Bago sisihin ang gateway

Nag-iingat ang Windows ng listahan ng resolver sa bawat adapter, kaya tiyakin kung ano talaga ang natanggap ng tunnel interface bago sisihin ang gateway.

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

Ang negatibong sagot ay nabubuhay sa cache nang mas matagal kaysa sa pagwawasto ng routing, at ang lipas na listahan ng suffix ay patuloy na nagpapadala ng mga query sa lugar na hindi kailanman nag-host ng zone. I-flush, itanong muli, at itala kung aling server ang sumasagot.

Dalawang mas maliit na kondisyon ang nagpapasya kung tatagal ang landas: hindi dapat mag-overlap ang mga address space, at ang network security group sa subnet ng resolver ay dapat tumanggap ng client pool, na isa pang source range lamang. Patunayan ito sa pamamagitan ng pagsusuri ng epektibong ruta mula sa gilid ng VM at isang direktang query mula sa kliyente, upang ang problema sa zone, problema sa suffix o filter ay hindi kailanman mapagkamalang kulang na transit.