د Azure سایټ تر سایټ VPN د NAT شاته پیر سره: د تفتیش لیست

دا تفتیشونه په ترتیب سره ترسره کړئ او په لومړي هغه کې ودرېږئ چې ناکامېږي. ډېری هغه راپورونه چې Azure د NAT شاته وسیله نه ملاتړ کوي، په واقعیت کې د پیر هغه پته ده چې Azure ورته نه شي رسېدلی، یا هغه ټنل چې هېڅکله د سم اړخ څخه نه پیلېږي. بهرنی ترانسپورت او داخلي لارښوونه دوه بېلې ستونزې دي، او د دوی ګډول یوه ماسپښین ضایع کوي. لاندې هر ګام یوه کتنه تولیدوي چې بل چاته یې سپارلی شئ.

ګام 1: تایید کړئ چې پیر په بشپړ ډول د NAT شاته دی

د وسیلې د WAN انټرفیس پته د هغې پتې سره پرتله کړئ چې Azure د دې لپاره ویني. که توپیر ولري، یو څه ژباړه کوي، او هغه ژباړونکی اوس ستاسو د VPN ډیزاین برخه ده. له عرضه کوونکي وپوښتئ چې نقشه اړوند ثابته ده که شریکه، ځکه شریکه نقشه بدلوي چې تاسو پر څه تکیه کولی شئ. هغه وسیله چې شخصي WAN پته لري او لېږد نه لري، د هغې وسیلې څخه بېله قضیه ده چې د ثابتې عامې نقشې سره د کیریر-ګریډ NAT شاته ده.

که دواړه پتې سره سمون وخوري، دلته ودرېږئ: NAT ستاسو ستونزه نه ده او د دې لیست پاتې برخه به مرسته ونه کړي.

په ټکټ کې دواړه پتې او د ژباړونکي ماډل ولیکئ. هغه یوه کرښه د دې لپاره چې ولې تنظیم شوی پیر ځواب نه ورکوي، بله پوښتنې مخه نیسي.

ګام 2: په دې سره سلا وکړئ چې څوک پیل کوي

د Azure VPN Gateway په اړه عامې پوښتنې د NAT-T ملاتړ یادوي او زیاتوي چې کورنی وسیله باید د NAT شاته کېدو پر مهال IPsec ټنل پیل کړي. دا د هغه څه سره سمون لري چې د حالت لرونکې ژباړې کار کوي، ځکه ژباړونکی نقشه ساتي ځکه چې داخلي وسیلې لومړی پاکټ لېږلی و. که د Azure څخه تمه وي چې پیل وکړي او هغه نقشه جوړولو لپاره هېڅ نه راځي، ټنل هېڅکله نه پیلېږي.

پیر داسې تنظیم کړئ چې د یوازې-ځوابوونکي تېروتنه ښکاره وي، او وګورئ چې وسیله پخپله بیا هڅه کوي که ټریګر ته اړتیا لري. ځینې وسیلې یوازې هغه وخت ټنل پورته کوي چې زړه راښکونکی ترافیک ښکاره شي، دا تر هغه وخته سمه ده چې زړه راښکونکی ترافیک هغه روغتیایي پلټنه شي چې هېڅکله نه راځي.

د لاسي پیل پر مهال په وسیله کې د IKE تبادله وګورئ؛ هلته چوپتیا د لارښوونې یا فایر وال ځواب دی، نه د Azure ځواب.

ګام 3: د پیر پته سمه کړئ

Azure ته په خپل ځایي شبکه لارښود شي کې د پیر لپاره د رسېدو وړ عامه پته غواړي، معمولا د وسیلې داخلي پتې پر ځای د ژباړونکي عامه پته. هغه پیژندنه چې وسیله ترې تصدیق کېږي بېله برخه ده او کولای شي په قانوني توګه د هغې پتې څخه توپیر ولري چې Azure پرې زنګ وهي. دواړه بېل وساتئ، ځکه د دوی بدلول د تصدیق ناکامي رامنځته کوي چې په بشپړ ډول د NAT ستونزې په څېر ښکاري.

که عامه پته بدله شي، هغه شی هم باید ورسره بدل شي. هغه نوم چې زوړې پتې ته حل کېږي، له هغې ثابتې پتې څخه بدتر دی چې په لاس تازه یې کوئ.

درې واړه ارزښتونه ولیکئ: د وسیلې ځایي پته، ژباړل شوې عامه پته، تنظیم شوې د پیر پیژندنه.

ګام 4: یوازې هغه پورټونه پرانیزئ چې NAT-T ورته اړتیا لري

NAT-T ESP د UDP دننه لېږدوي، او RFC 3948 هغه پوښښ بیانوي چې پکې پورټ 4500 د پورټ 500 پر لومړنیو خبرو اترو وروسته کارول کېږي. ستاسو فایر وال او ژباړونکی دواړه باید تبادله او د هغې بېرته ترافیک ته اجازه ورکړي. د یوې بېلې TCP پورټ اجازه ورکول د دې لارې په اړه هېڅ نه ثابتوي، او هغه قاعده چې وتل اجازه ورکوي خو ځواب نه، بیا هم ناکامېږي.

کله چې پیر پیل کوي او ژباړونکی حالت ساتي، د ننوتلو پورټ ثابت لېږد په اتوماتيک ډول نه اړین دی. دا هغه وخت اړین کېږي چې نقشه بې ثباته وي یا په لار کې یو څه حالت په تېري سره پای ته رسوي.

د ژباړونکي دواړو خواوو کې یو ځل کاپچر وکړئ؛ د پوښښ توپیر سمدلاسه ښکاري.

ګام 5: بهرنی ترانسپورت له داخلي لارښوونې جلا کړئ

هغه ټنل چې جوړېږي خو هېڅ نه لېږدوي، د لارښوونې ستونزه ده، نه د NAT-T ستونزه. سایټونو ته لا هم اړوند د ترافیک غورونکي، سره سمون لرونکي پته ځایونه، د لاسرسي قواعد او د اپلیکیشن شبکو لپاره بېرته لاره ورته اړتیا ده. له دې هېڅ هم بریالې IKE تبادله نه برابروي.

که دواړه سایټونه یو بل ته ننوتونکي شخصي حدونه کاروي، په ټنل کې دننه ژباړه خپلو قواعدو سره بېل ډیزاین دی. یوازې د دې لپاره چې بهرنی لارښود د کور روټر شاته دی، سبنیټ بیا شمېره مه کوئ.

له هر څه بدلولو مخکې ناکامي د پړاو له مخې ډلبندي کړئ، او هغه ډلبندي په ټکټ کې وساتئ تر څو بل کس له هغه ځایه پیل وکړي چې تاسو ودرېدلئ.