د Azure P2S DNS ناکامي کله چې resolver په جړ شوي VNet کې وي

کارن کولای شي خپل مجازي شبکه ته ورسیږي او بیا هم په جړ شوې شبکه کې نومونه حل نه کړي. Peering د gateway ترانزیټ نه دی تر څو چې دواړه خواوې ووایي.

VM ته ping وکړئ او ځواب درکوي؛ د هغې نوم وپوښتئ او کارن وایي چې host نامعلوم دی. کله چې resolver په جړ شوې مجازي شبکه کې وي نه په هغه شبکه کې چې VPN gateway لري، د دې دوو پایلو جوړه تمه کیدونکې ده، او د resolver هر ډول څیړنه دا نه بدلوي. هغه څه چې ورک دي د routing تړون دی چې peering یې په ډیفالټ توګه ساتي. دوه ټوپولوژي په کاغذ باندې نږدې ورته ښکاري، او د کار کوونکي او مات شوي ترمنځ توپیر په سم لوري ایښودل شوي د peering سویچونو یوه جوړه ده.

تصور وکړئ یو لیپ ټاپ په VNet2 کې د یو gateway په لور تونل کوي، پداسې حال کې چې د DNS خدمت کوونکی domain controller په VNet1 کې ناست دی.

دوه ټوپولوژي، یو توپیر

resolver د gateway په خپله مجازي شبکه کې کیږدئ او نوم د تونل د پورته کیدو په شیبه حل کیږي. په دې لټون کې هیڅ peering تنظیم برخه نه اخلي.

همدا resolver د peering بلې خوا ته یوسئ او کارن بیا هم له VM څخه ځواب ترلاسه کوي خو نوم نامعلوم پاتې کیږي. سند، تونل او کارن نه دي بدل شوي. یوازینی شی چې خوځیدلی هغه دا دی چې resolver چیرته اوسیږي. peering هغه ته دې پتې ته لار ورکړه، نه gateway ته د هلته ترافیک وړلو واک.

خوا A: د gateway په مالک باندې د gateway ترانزیټ اجازه ورکړئ

peering دوه مجازي شبکې یوځای کوي، خو دا یوځای کیدل د gateway له لارې راتلونکي ترافیک لپاره انتقالي نه دي، او د point-to-site غوښتنه سم همداسې راتلونکې ده. نو ځکه په VNet2 کې gateway د دې واک نه لري چې لټون VNet1 ته وسپاري تر څو چې ډیزاین اجازه ورنکړي. اجازه هغه سویچ دی چې په peering باندې دی او د gateway لرونکې شبکې ملکیت دی.

په VNet2 څخه VNet1 ته د peering په لور Allow gateway transit تنظیم کړئ. دا ځانګړتیا د peering شي پورې اړه لري، نه د gateway سرچینې پورې، نو هغه په peering blade کې لولئ او بدل یې کړئ. ټوله خوا A همدا ده.

خوا B: په ملګري باندې لرې gatewayونه وکاروئ

بله نیمایي د هندارې انځور دی: په VNet1 څخه VNet2 ته بیرته د peering په لور Use remote gateways فعال کړئ. همدا بیرغ په دواړو سرونو، یا یوازې په یوه سر کې بل کول نیمګړې لار او اصلي نښه نه لاس وهل شوې پریږدي. یوازې هغه شبکه چې VPN gateway لري ترانزیټ ته اجازه ورکوي، او ملګری هغه خوا ده چې هغه کاروي.

پر ځای د دې چې په وروستي خلاص شوي پورټل blade باور وکړئ، په دواړو شبکو کې دواړه ځانګړتیاوې ولولئ.

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

جوړه سره نږدې لیدل د نسکور شوي تنظیم نیولو تر ټولو ګړندې لار ده. هغه peering چې د gateway په خوا کې AllowGatewayTransit false راپور ورکوي، ټوله ناکامي پرته د packet capture تشریح کوي.

کارن باید لا هم څه ترلاسه کړي

Routing اړین دی او کافي نه دی، ځکه چې point-to-site profile باید کارن ته هغه DNS پته هم ورکړي چې د ترانزیټ له کار کولو وروسته ځواب ووایي. د پلیټ فارم resolver هغه پته نه ده: هغه د مجازي شبکې سره تړلو Azure Private DNS زونونو ته ځواب وایي، خو د هغه زون لپاره هیڅ نه چې ستاسو په خپلو ډایرکټري سرورونو کې کوربه دی، او دا همدا ډیپلوی دی چې هغه کاروي. یو کارن هلته اشاره کړئ او عام نومونه په خوښۍ حل کیږي پداسې حال کې چې داخلي host نامعلوم پاتې کیږي.

له تړل شوي لیپ ټاپ څخه resolver وپوښتئ مخکې لدې چې بل څه بدل کړئ.

nslookup dc01.corp.example 10.1.0.4

د وخت ختمیدل وایي چې لار لا هم نشته. باوري ځواب ستونزه بیرته کارن ته ټېل وهي، معمولا هغه ضمیمه چې هیڅکله نه ورزیاتېږي، نو لنډ نومونه یو عام resolver ته ځي چې په خوښۍ یې ناکاموي.

همدا تړون د site-to-site په خوا کې پرتله کړئ

د دې هیڅ یو هم په ځانګړي ډول لیپ ټاپونو پورې اړه نه لري. کارن په site-to-site کې د یوې څانګې سره بدل کړئ او د دواړو خواوو شرط بیرته راځي: څانګه مستقیم د gateway شبکې ته رسیږي، او دوه شبکې لرې خدمت لا هم د peering شاته دی.

ترانزیټ باید په دواړو peeringونو کې ورکړل شي، او هغه سویچ چې ورکوي یې په peering کې اوسیږي نه د کارن په ډول.

مخکې لدې چې gateway ته ګناه ورکړئ

Windows د هر adapter لپاره د resolver لیست ساتي، نو مخکې لدې چې gateway ته ګناه ورکړئ تایید کړئ چې د تونل انټرفیس واقعا څه ترلاسه کړل.

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

منفي ځواب په cache کې د routing سمون څخه زیات ژوند کوي، او زوړ ضمیمه لیست خپلې پوښتنې هغه ځای ته استوي چې زون هیڅکله هلته کوربه نه و. پاک کړئ، بیا وپوښتئ، او یادداشت کړئ چې کوم سرور ځواب وایي.

دوه کوچني شرطونه پریکړه کوي چې لار به ودریږي: د پتو سیمې باید یو بل ته نه ننوځي، او د resolver په subnet کې د شبکې امنیتي ډله باید د کارن حوض ومني، چې یوازې بله سرچینه ساحه ده. دا په VM خوا کې د اغیزمنې لارې کتنې او له کارن څخه په یوه مستقیمه پوښتنه سره ثابت کړئ، تر څو د زون ستونزه، د ضمیمې ستونزه یا فلټر هیڅکله د ورک ترانزیټ سره غلط نه شي.

اړوندې مقالې