DNS i Azure P2S dështon kur resolver-i ndodhet në një VNet të çiftuar

Bëni ping nga VM-ja dhe ajo përgjigjet; pyesni për emrin e saj dhe klienti thotë se host-i është i panjohur. Kur resolver-i ndodhet në një rrjet virtual të çiftuar dhe jo në atë që përmban gateway-in VPN, ai çift rezultatesh është i pritshëm, dhe asnjë sasi e diagnostikimit të resolver-it nuk e ndryshon. Ajo që mungon është një kontratë routimi që çiftimi e mban si parazgjedhje. Dy topologji duken pothuajse identike në letër, dhe hendeku mes funksionimit dhe prishjes është një çift çelësash çiftimi të vendosur në drejtimin e duhur.

Imagjinoni një laptop që tunelon në një gateway në VNet2, ndërsa kontrolluesi i domenit që shërben DNS ndodhet në VNet1.

Dy topologji, një ndryshim

Vendosni resolver-in brenda rrjetit virtual të gateway-t dhe emri zgjidhet në momentin që tuneli ngrihet. Asnjë cilësim çiftimi nuk merr pjesë në atë kërkim.

Zhvendosni të njëjtin resolver përtej një çiftimi dhe klienti vazhdon të marrë përgjigje nga VM-ja, ndërsa emri mbetet i panjohur. Certifikata, tuneli dhe klienti janë të pandryshuar. E vetmja gjë që lëvizi është ku jeton resolver-i. Çiftimi i dha një rrugë drejt atij adresi, jo autoritet gateway-t për të mbartur trafik atje.

Ana A: lejoni transitin e gateway-t te pronari i gateway-t

Një çiftim bashkon dy rrjete virtuale, por bashkimi nuk është kalimtar për trafikun që vjen përmes një gateway-t, dhe një kërkesë pikë-në-sajt vjen pikërisht kështu. Prandaj gateway-i në VNet2 nuk ka bazë për t'ia dorëzuar kërkimin VNet1 derisa dizajni ta lejojë. Leja është një çelës në çiftimin që zotërohet nga rrjeti me gateway-in.

Vendosni Allow gateway transit në çiftimin e VNet2 drejt VNet1. Vetia i përket objektit të çiftimit, jo burimit të gateway-t, prandaj lexohet dhe ndryshohet në tehun e çiftimit. Kjo është e gjithë ana A.

Ana B: përdorni gateway-e të largët te partneri

Gjysma tjetër është imazhi i pasqyrës: në çiftimin e VNet1 përsëri drejt VNet2 aktivizoni Use remote gateways. Ndriçimi i të njëjtit flamur në të dy skajet, ose vetëm në njërin, lë një rrugë gjysmë të ndërtuar dhe simptomën origjinale të paprekur. Vetëm rrjeti me gateway-in VPN lejon transitin, dhe partneri është ana që e përdor atë.

Lexoni të dyja vetitë në të dy rrjetet në vend që t'i besoni tehut të portalit që hapët herën e fundit.

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

Të shohësh çiftin krah për krah është mënyra më e shpejtë për të kapur një cilësim të përmbysur. Një çiftim që raporton AllowGatewayTransit false në anën e gateway-t shpjegon të gjithë dështimin pa kapje paketash.

Çfarë duhet të marrë ende klienti

Routimi është i nevojshëm dhe jo i mjaftueshëm, sepse profili pikë-në-sajt duhet t'i japë klientit edhe një adresë DNS që përgjigjet pasi transiti funksionon. Resolver-i i platformës nuk është ajo adresë: përgjigjet për zonat Azure Private DNS të lidhura me rrjetin virtual, por asgjë për një zonë të strehuar në serverat tuaj të drejtorisë, dhe kjo është ajo që përdor ky vendosje. Drejtojeni një klient atje dhe emrat publikë zgjidhen me gëzim ndërsa host-i i brendshëm mbetet i panjohur.

Pyetni resolver-in nga laptopi i lidhur përpara se të ndryshoni çdo gjë tjetër.

nslookup dc01.corp.example 10.1.0.4

Një afat i skaduar thotë se rruga ende mungon. Një përgjigje autoritative e shtyn problemin përsëri te klienti, zakonisht një prapashtesë që nuk shtohet kurrë, kështu që emrat e shkurtër udhëtojnë drejt një resolver-i publik që i dështon me gëzim.

Krahasoni të njëjtën kontratë në anën sajt-në-sajt

Asgjë nga kjo nuk i përket posaçërisht laptopëve. Zëvendësoni klientin me një degë në sajt-në-sajt dhe kërkesa dyanshme kthehet: dega mbërrin drejtpërdrejt në rrjetin e gateway-t, dhe një shërbim dy rrjete larg është ende pas çiftimit.

Transiti duhet të jepet në të dy çiftimet, dhe çelësi që e jep jeton në çiftim dhe jo në llojin e klientit.

Përpara se të fajësoni gateway-in

Windows mban një listë resolver-ësh për çdo përshtatës, prandaj konfirmoni çfarë mori vërtet ndërfaqja e tunelit përpara se të fajësoni gateway-in.

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

Një përgjigje negative i mbijeton korrigjimit të routimit në cache, dhe një listë e vjetruar prapashtesash vazhdon të dërgojë pyetje diku ku zona nuk është strehuar kurrë. Pastroni, pyesni përsëri dhe shënoni cili server përgjigjet.

Dy kushte më të vogla vendosin nëse rruga mbahet: hapësirat e adresave nuk duhet të mbivendosen, dhe grupi i sigurisë së rrjetit në nënrrjetin e resolver-it duhet të pranojë grupin e klientëve, që është thjesht një interval tjetër burimi. Vërteteni atë me një kontroll rrugësh efektive nga ana e VM-së plus një pyetje të drejtpërdrejtë nga klienti, që një problem zone, një problem prapashtese ose një filtër të mos ngatërrohen kurrë me transit që mungon.