L2TP/IPsec د NAT له لارې: په رېښتیا کې څه ماتېږي او ولې
NAT traversal ESP په UDP کې اچوي، او نقشه اخیستنه، فایر وال او آپریټر هر یو په بېل ډول ناکامېږي۔ د کلاینټ د ملامتولو دمخه پړاو وټاکئ۔
دا ادعا چې NAT د L2TP/IPsec ماتوي نیمه سمه ده او له همدې امله بې ګټې۔ د پتې ژباړه نورماله ده، NAT traversal په دقیق ډول د همدې ژوندي پاتې کېدو لپاره شته، او هرې ورځې میلیونونه کلاینټونه د روټر له شا څخه نښلېږي۔ څه چې ماتېږي هغه د یو ځانګړي تبادلې یو ځانګړی پړاو دی: IKE هیڅکله ځواب نه ترلاسه کوي، انکپسول شوی ټنل د هغې پالیسۍ له خوا غورځول کېږي چې یوازې یو پروتوکول ته اجازه ورکوي، یا د ژباړې نقشه هغه مهال ختمېږي چې ټنل بې کاره وي۔ کله چې پوه شوې چې په کوم پړاو کې یاست، حل معمولاً یو قاعده یا keepalive وي، نه نوی VPN ډیزاین۔
افسانه خپله غلطه پوښتنه ده
ګټوره پوښتنه دا نه ده چې «ایا NAT دا ماتوي»، بلکې دا ده چې «د تبادلې کومه برخه ژباړل کېږي، او ژباړونکې وسیله ورسره څه کوي»۔ L2TP/IPsec یو طبقه يي پروتوکول دی: IKE خبرې اترې کوي، ESP ساتنه کوي، او L2TP په همدې ساتنه کې PPP لیږدوي۔ د پتې ژباړه له هرې طبقې سره بېلابېل تعامل کوي، او د ناکامۍ نښې هغه مهال توپیرېدای شي چې د تېروتنې ډیالوګ پرځای د خبرو اترو پړاو ته وګورئ۔
هغه روټر چې په بریالیتوب سره ویب ګوري یوازې دا ثابتوي چې د سرچینې پورټ ژباړې سره TCP کار کوي۔ دا د UDP 500، UDP 4500 یا پروتوکول 50 په اړه هیڅ نه وايي، او دا ځای پرځای کول په همدغو دریوو تکیه دي۔
پړاو 1: IKE باید په هر حال ځواب ترلاسه کړي
لومړنۍ تبادله د UDP 500 په بڼه ځواب ورکوونکي ته ځي۔ که هیڅ ځواب بیرته رانه شي، نور هر څه بې معنا دي: مخکې شریک شوی کیلي، وړاندیز او اعتبارنامې ټولې نالوستل شوې پاتې کېږي۔ د کلاینټ د وخت ختمېدو څخه اټکل مه کوئ، غوښتنه او ځواب وګورئ:
sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas
بې ځوابه غوښتنه معمولاً دا مانا لري چې فایر وال یا پورتنۍ آپریټر پاکټ غورځوي، نه دا چې سرور یې رد کړی۔ هغه ځواب چې د خبرتیا بار کې وړاندیز یا د سند ستونزه ونوموي، دا مانا لري چې پاکټونه ورسېدل او خبرې اترې د منځپانګې له امله ناکامې شوې، چې دا بشپړه بېله ترمیم دی۔
کله چې دواړه خواوې د ژباړې شا ته وي، پیلوونکی یوازې ځواب ورکوونکي ته رسېدل غواړي، نو ډېری کلاینټ اړخې ځای پرځای کول له 1 پړاو څخه کار کوي۔ د سرور اړخه کوربه توب هغه ځای دی چې د راتلونکې ستونزه پیلېږي، او له همدې امله دې دوو حالتونو ته باید هیڅکله د یو په توګه ونه ګورو۔
پړاو 2: انکپسولیشن هغه څه بدلوي چې فایر وال یې ویني
ESP یو IP پروتوکول دی، نه TCP یا UDP پورټ، او عادي پورټ پتې ژباړه د بیا لیکلو لپاره د پورټ ساحه نه لري۔ له همدې امله NAT traversal ساتل شوی بار UDP 4500 ته لېږدوي: انکپسولیشن ژباړونکې وسیلې ته هغه څه ورکوي چې ژباړل یې پېژني۔ کله چې دا وشول، یوازې د UDP 500 لپاره لیکل شوی فایر وال قاعده خبرو اترو ته اجازه ورکوي او ټنل غورځوي، چې هغه ګډوډونکی نتیجه رامنځته کوي چې لاګ پکې بریالی 1 پړاو او هیڅ ترافیک نه ښیي۔
پخپله IKE تبادله هم کولای شي د NAT له کشف وروسته UDP 4500 ته ولاړ شي، چې هغو کسانو ته حیرانتیا ده چې یوازې 500 ته اجازه ورکړې۔ په لاره کې دواړه پورټونه په دواړو لورو اجازه کړئ، او په یاد ولرئ چې حالت لرونکی فایر وال یوازې هغه مهال بهیر ساتي چې ترافیک ویني۔
پروتوکول 50 لا هم د ژباړې پرته لارو او هغو لارو کې مهم دی چې منځنی بکس یې د اجازې لپاره تنظیم شوی۔ که تاسو د لرې کولو له لارې تشخیص کوئ، د قاعدو ډېرول پرځای فرضیه بنده کړئ: 500، 4500 او ESP ته اجازه ورکړئ، تثبیت کړئ چې ټنل پورته کېږي، بیا هغه څه لرې کړئ چې غیرضروري ثابت شول۔ هغه قاعده چې هیڅوک یې نه شي تشریح کولای، هغه قاعده ده چې هیڅوک به یې لرې نه کړي کله چې د بل اختلال لامل شي۔ تنګونه د بدلون په ثبت کې د هغه پړاو سره ولیکئ چې سمه کړې یې ده، تر څو بل انجنیر د همدې ګوتې قاعدې پرځای ستاسو له شاهدو پیل کړي۔
پړاو 3: نقشه اخیستنه ختمېږي او ټنل مري
ژباړونکې وسیله د هغو بهیرونو لپاره حالت ساتي چې لیږدوي یې، او دې حالت ژوند لري۔ L2TP/IPsec ټنل هغه مهال لږ ترافیک لیږدوي چې هیڅوک یې نه کاروي، نو بې کاره ټنل کولای شي خپله نقشه اخیستنه ژوندی پاتې شي او د راستنېدونکي ترافیک منل بند کړي۔ کلاینټ باوري پاتې کېږي چې نښلېدلی، سرور هیڅ نه ویني، او لومړنۍ نښه معمولاً د اپلیکیشن د وخت ختمېدل دي نه د VPN تېروتنه۔
د مړه همکار کشف او NAT keepalive د همدې لپاره دي، او دواړه سرونه باید د هغو لیږلو ته چمتو وي۔ که ستاسو سرور د ژباړې شا ته وي، د Windows په اړخ کې غوښتنه یوه مستنده راجستر تنظیم دی چې سرور دې خپلو وتلو پاکټونو لپاره UDP انکپسولیشن فرض کړي؛ پرته له دې ځواب ورکوونکی هغه ESP لیږي چې ژباړونکې وسیله یې بیرته نقشه کولای نه شي۔ دا د سرور د ترتیباتو مسئله ده، نه د کلاینټ۔
د WAN پتې بدلون له بل لوري ورته نتیجه ورکوي: نقشه اخیستنه د نوي پتې شاوخوا بیا جوړېږي، او پخوانی امنیتي ټولګه اوس هغه جوړه ته اشاره کوي چې نوره نشته۔ د بیا نښلېدو چلند د کلاینټ پلي کولو پورې اړه لري، او له همدې امله «د روټر له بیا پیل وروسته بیا ونښلوه» په یو کلاینټ کار کوي او په بل کې لاسي بدلونکي ته اړتیا ده۔
د آپریټر کچې NAT شا ته کوربه توب بېله ستونزه ده
که وغواړئ په کور کې L2TP/IPsec سرور کوربه کړئ او له دباندې ورته ورسیږئ، غوښتنه نه غوښتل شوې راتلونکې رسېدنه ده، او NAT traversal دا نه برابروي۔ ستاسو د روټر مخې ته د آپریټر کچې NAT مانا دا ده چې هیڅ پورټ نشته چې فوروډ یې کړئ او رسېدونکی شئ، ځکه عامه پته شریکه ده او نقشه اخیستنه یوازې وتلې ده۔
هیڅ IPsec پاس-تھرو چیک باکس دا نه بدلوي، او هیڅ کلاینټ ترتیبات یې جبران نه کوي۔ ملاتړ شوي ځوابونه هغه پته ده چې په رېښتیا رسېدونکې ده، کوربه شوی پایټ، یا هغه جوړښت چې هر ګډونوال پکې وتلې اړیکه جوړوي۔ د UDP انکپسولیشن مشخصات د موجودو بهیرونو لپاره د ژباړې ستونزه حلوي؛ هلته راتلونکې لاره نه جوړوي چې آپریټر یې نه وړاندې کوي۔
نو د اټکل پرځای شبکې پرتله کړئ۔ هماغه وسیله او پروفایل بل اجازه لرونکي شبکه ته یوسئ او وګورئ چې هلته کوم پړاو ناکامېږي۔ که بل ځای کار وکړ، توپیر په لاره کې دی، او دا پلټنه ټول ترتیباتو پرځای پورتنو دریو پړاوونو ته محدوده کوي۔