د VPN کوم پړاو ناکام شو: IPsec، L2TP کنټرول یا PPP تصدیق
وروستی بریالی پړاو پیدا کړئ او یوازې هغه پوړ سم کړئ: IPsec، L2TP کنټرول چینل، PPP تصدیق یا د پتې ټاکل.
تاسو پټنوم بدل کړ او هیڅ ونه خوځېد، ځکه چې ستونزه هیڅکله په PPP کې نه وه. L2TP/IPsec د پنځو بشپړو بېلو لېږدونو لپاره یوه د اړیکې تېروتنه راپور کوي، او هر لېږد خپله ترمیم لري. په مخالف لوري کار وکړئ: وروستی بریالی پړاو پیدا کړئ او یوازې هغه څه بدل کړئ چې ترې وروسته راځي. لاندې ترتیب دا هم ټاکي چې کوم شواهد لومړی راټول کړئ.
پر څلورو پوښتنو په ترتیب ځواب ورکړئ
نوی هڅه جبري کړئ، ځکه چې ځینې کلینټان تر هغه پورې پخوانۍ تېروتنه ښیي چې پروفایل قطع او بیا وصل نه شي. بیا دې ته ځواب ورکړئ: آیا IPsec امنیتي ټولنه وه، آیا L2TP کنټرول اړیکه او زنګ راڅرګند شو، آیا PPP د تصدیق پرېکړې ته ورسېد، او آیا IPCP کلینټ ته پته ورکړه؟ لومړی نه هغه پړاو دی چې تاسو یې سمولئ. ترې وروسته هر څه نه دي ازمویل شوي، نو کله چې ټولنه هیڅکله نه وه، رد شوی کارنوم هیڅ ثابتولی نشي.
د پرتله کولو دمخه په دواړو خواوو ساعتونه همغږي کړئ. هغه بیا هڅه چې IPsec یې پاک کړ او په PPP کې ناکامه شوه، د یوې ناکامۍ په څېر ښکاري کله چې کلینټ یوازې وروستی پیغام ښیي او د سرور ثبت لا هم پخوانۍ هڅه لري. د ترټولو لوړ غږ کرښې له مخې نه، د وخت نښې له مخې ولولئ.
کله چې یوازې د کارونکي سکرین شاټ ولرئ، پر ترټولو ارزانه وېش تکیه وکړئ: غلط مخکې شریک شوی کیلي او هغه xl2tpd چې هیڅکله ځواب نه ورکوي په Windows ډیالوګ کې یو شان متن جوړوي، خو یو ته په دواړو خواوو بدل شوی راز اړین دی او بل ته په سرور کې پیل شوی ډیمون یا د وال نومره. منځنی وسیله نشي کولی دننی 1701 وغورځوي کله چې د لېږد حالت IPsec هغه تړلی وي، نو داسې لار-چاڼ مه لټوئ چې نشته.
هر پوړ په رښتیا څه لري
IPsec د دوو همکارانو ترمنځ پاکټونه ساتي؛ L2TP د هغې ساتل شوې لارې دننه PPP غونډه وړي، ځکه هم RFC 3193 د خپل تونل پرځای د لېږد حالت ټاکي. د کلینټ لیبل L2TP وایي، نو تونل او ننوتل د یو میکانیزم په څېر احساس کېږي. داسې نه دي: L2TP کنټرول اړیکه هلته د تونل پایونه تصدیقوي چې ځای پرځای کول یې فعالوي، او PPP د سرور تګلارې له مخې کارونکی جلا د CHAP، PAP یا MS-CHAPv2 له لارې تصدیقوي.
دا وېش هغه دوې پټې خبرې تشریح کوي چې خلک یې دوامداره ګډوډوي. مخکې شریک شوی کیلي د IPsec همکاران تصدیقوي. کارنوم او پټنوم کارونکی PPP ته پېژني. د Windows شریک شوی راز په هغه پروفایل کې بیا ټایپ کول چې د سندونو سره تصدیق کوي په ناکام پړاو کې هیڅ نه بدلوي، او د PPP پټنوم سمول نشي کولی ورکه ساتل شوې چینل برابر کړي. همدا ځان ساتنه د هویت کتنې لپاره هم ده: د تونل ترلاسه کولو لپاره د همکار هویت یا د سند اعتبار مه بندوئ، ځکه چې بیا لار نښلوي، نه همکار.
تصدیق هم د PPP پای نه دی. وروسته له دې چې کارونکی ومنل شو، IPCP د کلینټ پتې او هغو DNS او WINS اختیارونو باندې خبرې کوي چې سرور یې د ورکولو لپاره چمتو دی. کلینټ کولی شي CHAP یا MS-CHAPv2 تېر کړي او بیا هم پرته له پتې پاتې شي، چې دا په PPP کې دننه ناکامي ده، نه د لارښوونې ستونزه. پرته له IPsec ساده L2TP سم او نه ساتل شوی پاتې کېږي، نو بریالۍ اړیکه هیڅکله ثابتولی نشي چې ټرافیک ساتل شوی; وګورئ سرور څه غواړي، نه د کلینټ لیبل.
د لومړي ورک پړاو پر بنسټ پرېکړه وکړئ
جدول د لومړي ورک توکي له مخې له کیڼ څخه ښي خوا ته ولولئ. ښي کالم په هغه شیبه کې یوازې ارزښت لرونکی کار دی؛ د هغه کیڼ اړخ هر څه مخکې ثابت شوي، او بیا ازموینه یې پرته له معلوماتو د خنډ کړکۍ سوځوي.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
درې کرښې د خبرتیا وړ دي. د 1701 کرښه هغه ځای دی چې د NAT شاته Windows کلینټان معمولاً کښېني: ټولنه بشپړېږي، بیا هیڅ نه رسیږي، او لامل بد پټنوم نه بلکې انکپسولیشن دی. د IPCP کرښه هغه ده چې په غلطه توګه د لار ستونزه لوستل کېږي، ځکه Windows ورکه پته د 720 تېروتنې په څېر پېچي او د ټسۍ آیکون یوازې وایي چې اړیکه ناکامه شوه; هغه ناکامي له تصدیق وروسته او له لارښوونې مخکې ده. وروستۍ کرښه هیڅ د IPsec ناکامي نه ده، که څه هم آیکون قطع وایي.
هغه کمانډونه چې پوړونه بېلوي
د strongSwan لرونکي Linux سرور پر سر، swanctl --list-sas جوړې شوې ټولنې د همکار هویت سره لیست کوي، او ipsec statusall زاړه strongSwan او libreswan کوربه پوښي. تر هغې لاندې ip xfrm state د کرنل ریښتیني ټولنې ښیي، په داسې حال کې چې ss -lunp | grep 1701 ثابتوي چې xl2tpd چېرته تړل شوی. د کنټرول اړیکو او زنګونو راتلل لیدلو لپاره xl2tpd -D په مخکیني پلان کې وچلوئ، او د وړاندیز شوې طریقي او ځواب لیدلو لپاره په /etc/ppp/options.xl2tpd کې pppd ډیبګ فعال کړئ.
کله چې ثبتونه بریالی تصدیق ښیي، بل پوښتنه دا ده چې آیا IPCP بشپړ شو. وګورئ چې آیا د /etc/xl2tpd/xl2tpd.conf په [lns default] برخه کې ip range لا هم خالي پتې لري، او که کلینټ یې تمه لري آیا /etc/ppp/options.xl2tpd په رښتیا ms-dns او ms-wins لري. خالي شوی حوض او ورک DNS اختیار په تار کې بېل ښکاري: لومړی کلینټ پرته له پتې او له 720 سره پریږدي، دویم پته ورکوي خو هیڅ حل کوونکی نه، نو نومونه ناکامېږي پداسې حال کې چې خامو پتو ته ping کار کوي. د دواړو هیڅ یو د پټنوم بیا دننه کولو سره نه سمېږي.
پر کلینټ، د NetworkManager L2TP پلگ ان د pppd خبرې اترې په ژورنال کې لیکي، نو journalctl -u NetworkManager -b معمولاً تونل پورته، تصدیق رد شو له هیڅ تونل نشته څخه بېلوي. پر Windows، Get-VpnConnection د پروفایل ریښتیني تصدیق امستنې راپور کوي، او په Event Viewer کې د Application لاندې RasClient پېښې ناکامه برخه نوموي. کله چې ډیالوګ ډېر ناڅرګند وي، netsh ras set tracing * enable فعال کړئ.
نیول یوه پام ته اړتیا لري. د لېږد حالت IPsec سره دننی UDP 1701 کوډ شوی وي، نو د باندې انټرفیس نیول ESP ښیي، یا د NAT-T لاندې UDP 4500، او هیڅ L2TP نه. په نیول کې د 1701 نشتوالی تمه کېدونکی دی او د بند پورټ ثبوت نه دی; وګورئ چې ESP یا 4500 شمېرونکي ځوړند دي که نه.
NAT، MTU او لارې: چېرته چې سټک تاسو ته غلطي ورکوي
NAT هغه انګېرنې ماتوي چې مخکې له دې چې څه تصدیق شي. ESP خپل IP پروتوکول دی، نو ژباړونکې وسیله یې غورځوي پرته له دې چې همکاران انکپسول کړي; UDP 4500 همدا برابروي. پر هغه Windows سرور چې پخپله د کورني روټر یا د ورېځ NAT دروازې شاته وي، د IPsec پړاو د 789 تېروتنې سره ناکامېږي تر هغه چې د PolicyAgent کیلي لاندې AssumeUDPEncapsulationContextOnSendRule 2 ته وټاکل شي او ماشین بیا پیل شي، او ناکامي له بند پورټ څخه د بېلولو وړ نه وي. د NAT شاته کلینټان اسانه دي: د سرور پر سر عامه پته وي، نو پر UDP 4500 NAT-T هغوی وړي او هغه ارزښت ښکېل نه دی.
کله چې PPP پورته وي، د تور سوري لرونکی MTU مړ تونل ته ورته والی کوي: کوچني پاکټونه تېریږي، د TLS لاس ورکول یا د پاڼې لوډ ځوړند پاتې کېږي، او کلینټ ممکن لا هم وصل ښکاره کړي. مخکې له دې چې سرور ملامت کړئ، د انټرفیس MTU راټیټ کړئ یا په دروازه کې MSS کلېمپ کړئ. د وېشل شوي تونل لارښوونه بله دوکه ده; هغه سبنیټ چې په غلط ماسک سره ورکول کېږي تونل روغ او یو اپلیکیشن نه رسېدونکی پریږدي. خصوصي کوربه نوم خپل ګام زیاتوي: که پوښتنه د سیمه ییز حل کوونکي له لارې ووځي، نوم مخکې له دې چې هره لار وازمویل شي نه حل کېږي.
د اعتبارنامو له لمس کولو دمخه چک لیست
لیست په ترتیب سره ترسره کړئ او په لومړي ناکام توکي ودرېږئ. هر ګام ارزان دی، او هر یو د سمونو یوه بشپړه طبقه ایسته کوي.
- تایید کړئ چې ټولنه په دواړو خواوو کې ده، د همکار هویت سره سمون لري نه د وصل لیبل سره.
- تایید کړئ چې UDP 1701 xl2tpd ته رسیږي; پرته له زنګ ټولنه ستاسو ناکامي ده.
- د دې له اړخه چې پټنوم غلط دی، د PPP پرېکړه او که تصدیق شو، د IPCP پایله ولولئ.
- یوازې اوس اعتبارنامې د سرور هغه بڼه کې چې تمه یې لري بیا دننه کړئ، ځکه د ډومین مخکښ حساب بدلوي.
- که لا هم ناکامه شوه، دواړه خواوې د سمون شوو وخت نښو سره ونیسئ او پړاو په پړاو پرتله کړئ.
په دویم ګام کې درېدل یعني د لار یا انکپسولیشن ستونزه، او د پټنوم هیڅ سمون به یې ونه خوځوي. په درېیم ګام کې درېدل یعني ثبت لا مخکې د سمولو وړ طریقي یا پتې حوض نومولی دی. هرومرو بل بدلون هغه دی چې تاسو یې توجیه کولی شئ، او تاسو د هغو امستنو په ګرځېدو بندوئ چې هیڅکله ښکېلې نه وې.