ولې PPTP او L2TP/IPsec د کارن نوم له پوښتنې مخکې درېږي؟
د کارن نوم د پوښتنې نه راڅرګندېدل یعنې PPP هېڅکله پیل شوی نه دی، نو ستونزه په لېږد، کلي د تبادلې یا تونل جوړولو کې ده. د بیا نصبولو مخکې د پړاوونو ترتیب وګورئ۔
د کارن نوم د پوښتنې نه راڅرګندېدل یوه تشخيصي ډالۍ ده: PPP لا نه دی پیل شوی، نو حساب، پټنوم او د ډومېن تګلاره لا نه دي پوښتل شوي۔ په PPTP یا L2TP/IPsec اړیکه کې کلاینټ اعتبارنامې یوازې هغه وخت غواړي چې تونل شتون ولري او سرور PPP ناسته پیل کړې وي۔ هر څه چې د هغې شېبې مخکې ناکام شي، لېږد، د کلي تبادله یا تونل جوړول دي، چې له «VPN خراب دی» څخه ډېر کوچنی ساحه ده۔
نه راڅرګنده پوښتنه ستونزه درې پړاوونو ته محدودوي
وروستی پړاو ولیکئ چې په لیدلو بریالی شو، ځکه هر یو خپل مالک او خپل حل لري۔ د حساب تنظیمات اټکلول په داسې حال کې چې دوه پړاوه مخکې بند پاتې یاست، هغه لاره ده چې یوه ماسپښین ورکېږي۔
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
هغه کلاینټ چې بې پوښتنې وخت تېر شي هېڅکله IPsec اړوندتوب نه دی ترلاسه کړی، نو ستونزه په IKE کې ده یا په دې کې چې ستاسو پاکټونه ګېټوې ته رسېږي که نه۔ هغه چې د اعتبارنامو د کتنې خبر ورکوي او بیا لوېږي، د پیغام له اشارې څخه ډېر مخکې تللی و۔ پوښتنې ته د رد راتلل PPP تصدیق دی، او د هغې ځای د حساب په مقاله کې دی، په دې مقاله کې نه۔
لومړی پړاو: هغه پروتوکول چې فایر وال یې په چوپتیا غورځوي
PPTP د خپل کنټرول چینل لپاره TCP 1723 او د معلوماتو لارې لپاره IP پروتوکول 47 ته اړتیا لري، او دواړه جلا سفر کوي۔ ډېرې شبکې 1723 مخې ته پرېږدي او پروتوکول 47 غورځوي، چې له امله یې یو تونل جوړېږي چې خبرې اترې کوي او بیا هېڅ نه وړي۔ هغه روټر چې NAT کوي د GRE ملاتړې تېرېدنې ته هم اړتیا لري، او یوازې IPv6 لاسرسی لاره په هېڅ ترتیب کې PPTP نه شي وړلای۔
L2TP پر IPsec د IKE لپاره پورټ 500 او د NAT تېرېدو لپاره پورټ 4500 لګوي، بیا خپله L2TP ترافیک 1701 ته نغاړي، او کله چې اړوندتوب جوړ شي ESP خوندي بار وړي۔ دوه کنټرول پورټونه اجازه کړئ خو ESP نه، او تاسو به سم هغه نښه ترلاسه کړئ چې په سرلیک کې ده: لیدل کېدونکې پرمختګ، بیا د هر اعتبارنامې خبرو اترو مخکې مړ کلاینټ۔ د تلیفون هټسپاټ څخه ازموینه د کلاینټ ستونزې د لارې ستونزې څخه بېلولو ارزانه لاره ده۔
دویم پړاو: هغه کلي چې کلي نه ده، هغه وړاندیز چې نه وړاندې کېږي
ناسمه مخکې شریکه شوې کلي ژر او په چوپتیا ناکامېږي، او عادي بڼه یې هغه کلي ده چې په سکرین سمه ښکاري خو نښلول شوی کرښه ماتون یا په پای کې تشه لري۔ په Linux کلاینټ کې خبرې اترې اړ نه دي چې د رښتیا سرچینه وي: د NetworkManager L2TP پلگ ان رازونه د /etc/ipsec.d/ لاندې فایلونو کې ساتي، او هغه زوړ هر-اړیکه فایل چې /etc/ipsec.secrets لا یې هم شاملوي به د هغه فایل په ځای وکارول شي چې تاسو همدا اوس ټایپ کړ۔ هغه فایل خوندي ځای ته کاپي کړئ، د شاملولو له لارې یې وباسئ، او بیا کلي په لاس بیا ټایپ کړئ۔
د دې پړاو بله نیمایي وړاندیز دی۔ دواړه سرونه باید په یو شان 1م پړاو الګوریتم سیټ — کوډ کول، بشپړتیا او Diffie-Hellman ګروپ — او د 2م پړاو لپاره سم ESP بدلونونو سره موافق شي، که نه اړوندتوب هېڅ نه جوړېږي۔ هغه ګېټوې چې یوازې 3DES، SHA1 او MODP1024 وړاندې کوي به د غښتلي الګوریتمونو لپاره برابر شوی کلاینټ رد کړي، او د هغې لاګ د رد شوي بدلون نوم اخلي۔ لاګ د ناسموالي نوم اخلي که یې ولولئ پرته له دې چې خدمت بیا پیل کړئ۔ د فورمې له تار څخه د الګوریتم تار کاپي کولو پرځای ګېټوې ته ووایاست چې په رښتیا د کومو بدلونونو خبرې کوي: د هغې پتې ته نېښه شوی ike-scan هغه بدلونونه بېرته راوړي چې پرې به خبرې وکړي۔ که یوازینی وړاندیز هغه کوډونه وي چې ستاسو تګلاره نور اجازه نه ورکوي، سمون د ګېټوې په خوا کې دی، نه د کلاینټ په ټیټولو کې۔
په Windows کې کلي او د تصدیق طریقه د VPN پروفایل کې دي، او ناسموالی د اعتبارنامې پوښتنې مخکې ښکاري نه وروسته۔ چېرې چې ترلاسه کوونکی Windows Server وي، ډاډ ترلاسه کړئ چې د لرې لاسرسي رول نصب دی، سند د هغه نوم سره سم دی چې کلاینټونه پرې نښلي، او هېڅ پورټ فلټر له پورتنیو پروتوکولونو څخه تنګ نه دی۔
دریم پړاو: تونل شته او PPP نه پیلېږي
کله چې IKE بشپړ شي او پوښتنه لا هم راڅرګنده نه شي، فایر وال ته نه، تونل ډیمون ته وګورئ۔ L2TP د UDP 1701 پر اورېدونکي شي ته اړتیا لري — په Linux کې xl2tpd یا kl2tpd، په Windows کې د لرې لاسرسي خدمت — او نصب شوی خو بند خدمت د کلاینټ له اړخه سم لکه غورځول شوی پاکټ ښکاري۔ د هغو قواعدو بیا پرانیستلو مخکې چې تاسو لا دمخه تایید کړي، اورېدونکی وګورئ۔ بیا PPP باید خبرې وکړي، او لومړنی LCP تبادله هماغه ځای دی چې چوپ ناکامي معمولاً پرې کېږي۔
په دې پړاو کې یوه تله هېڅ د شبکې ستونزه نه ده: Windows یوازې د یو ټاکلي VPN ډول یوه اړیکه په یو وخت اجازه ورکوي، نو دویمه هڅه د 937 تېروتنه بېرته راوړي، «د دې ډول بله اړیکه کارېږي»۔ دا یو ځایي قاعده ده، او د هغې د تېرېدو لاره بله وسیله، بل د تونل ډول، یا د هغې یوازینې اړیکې شریکول دي چې لا دمخه شته۔
د اټکل کولو پرځای لاګ د پړاوونو په ترتیب ولولئ
کلاینټ ودروئ، بیا یې پیل کړئ، او برخې د هغه ترتیب له مخې ولولئ چې لاګ لیکي۔ یعنې لومړی IPsec ډیمون — strongSwan یا Libreswan، او ipsec --version وایي کوم یو — بیا L2TP ډیمون، بیا pppd۔ کومه برخه چې د ناکامۍ مخکې وروستی ځل لیکلی وي هغه د څېړنې پړاو په نښه کوي، ځکه په ترتیب کې له هغې وروسته هر څه هېڅ ونه ګرځېدل۔
د ساتل شوې ناستې پرځای نوي اړیکې سره تایید کړئ، ځکه له کاش څخه بیا نښلېدونکی کلاینټ د تبادلې برخې پرېږدي او زوړ نتیجه بیا تولید کړي۔ رسېدل، د کلي تبادله، تونل او PPP یو یو، په همدې ترتیب تایید کړئ۔ بیا نه راڅرګنده پوښتنه معما پاتې کېدل بندوي او د هغې لیست دویمه کرښه ګرځي چې په رښتیا پرې کار کېدای شي۔ هماغه لیست تاسو شبکه ټیم ته ورکوئ، چې بل ډول به یې له هغوی غوښتل چې د نه پیل شوي ډیمون کې اوسېدونکې ستونزې لپاره فایر وال وګوري۔