L2TP/IPsec ناکامېږي: IPsec، د تونل تصدیق یا PPP ننوتل جلا کړئ

په يوه L2TP/IPsec اړيکه کې درې شیان تصدیق کېږي، او یوازې یو یې هغه شخص ته اړه لري چې ډایل کوي۔ IPsec د تونل پای ټکي ثابتوي، L2TP کنټرول اړيکه کولای شي همکاران بيا په خپل راز ثابت کړي، او بيا PPP د غونډې دننه کارن حساب ثابتوي۔ هرې مرحلې کې ناکامي په کارن ډیالوګ کې د عمومي ننوتلو تېروتنې په څېر ښکاري او په سرور لاګ کې بشپړ بل ډول ښکاري۔ مرحلې په ترتیب سره بشپړې کړئ او په لومړۍ ناکامه کې ودروئ، ځکه چې له نه ازمېل شوې مرحلې لاندې هره مرحله هم نه ازمېل شوې ده۔

درې د تصدیق مرحلې، درې بېلې پېژندنې

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

L2TP کنټرول اړيکه کولای شي دویمه، جلا ننګونه-ځواب تبادله ورزیات کړي، چې د دواړو پایونو لخوا د ساتلو وړ شریک راز لخوا چلېږي۔

RFC 2661 هغه کنټرول اړيکه تصدیق اختیاري کوي، چې بیانوي ولې ورته تېروتنه په دوو سرورونو کې بېلې نښې جوړوي۔ هغه ځای پرځای کول چې هېڅکله د تونل راز نه وي تنظیم کړی، مرحله بشپړه پرېږدي؛ هغه چې یوازې یوې خوا ته یې تنظیم کړی، د PPP وړاندې کېدو دمخه ناکام کېږي۔ بيا PPP کارن د PAP، CHAP یا MSCHAPv2 سره تصدیقوي او نوم هغه حساب ذخیرې ته ورکوي چې ځایي، په chap-secrets یا په RADIUS کې وي۔ په هغه وخت کې غلط پټنوم لاهم تاسو ته کارکوونکی تونل او ناکامه غونډه پرېږدي۔

د ترتیب بدلولو دمخه د ودروې ځای ولولئ

په ipsec --version پیل وکړئ چې پوه شئ حالت بهرنۍ strongSwan ته اړه لري که Libreswan ته۔ بيا سرور لاګ ولولئ، نه کارن ډیالوګ، ځکه سرور ثبتوي چې کومې مرحلې انکار وکړ۔

معمولاً يوه کرښه ټکټ حل کوي: د IKE یا وړاندیز شکایت لومړۍ مرحله، د کنټرول اړيکې پیغام دویمه مرحله، او د PPP طریقه یا حساب انکار درېیمه مرحله۔ هغه کرښه د وخت ټاکلو سره ټکټ کې کاپي کړئ۔ له کارن خوا اټکل کول هغه یوازینی شاهد ضایع کوي چې تاسو دمخه لرئ۔

د کلي مواد او پټنومونه له هغه پيسټ بهر وساتئ؛ د مرحلې نوم کار لارښوونه کوي، او افشا شوی مخکې شریک شوی کلي ټکټ په بدو پایلو بیا پرانیزي۔

لومړۍ مرحله: ایا IPsec اتحادیه لري؟

په strongSwan ipsec statusall یا په Libreswan ipsec whack --status وچلوئ او د صفر نه لوی شمېرونکو سره ټینګه شوې اولادي اتحادیه ولټوئ۔ ip xfrm state په دواړو کې د کرنل لید ښیي۔ د اوښتونکو شمېرونکو سره نصب شوې SA جوړه مانا دا ده چې لومړۍ مرحله بشپړه شوه او تاسو کولای شئ مخکې لاړ شئ۔

د اتحادیې بشپړ نشتوالی د همکار پتې، د وړاندیزونو ټولګې یا مخکې شریک شوي کلي ته اشاره کوي، او کله ناکله هغه وسیلې ته چې UDP 500 بيا لیکي خو UDP 4500 غورځوي۔ هغه اتحادیه چې ټینګېږي او بيا څو ثانیې وروسته ورکېږي، معمولاً د دوو پایونو ترمنځ د ژوند مودې ناسم والی دی نه د اعتبار ستونزه۔ مخکې له دې چې څه بيا ولیکئ، وګورئ چې دواړه خواوې ورته کوډکول او هش وړاندیزونه لیستوي۔ که نه، هېڅ کلي به هېڅکله کار ونه کړي۔

تر هغه چې اتحادیه ورکه ده ودروئ۔ په هغه وخت کې PPP تګلارې سمول هېڅ نه بدلوي او ریښتینې خرابي له بل شخص څخه پټوي۔

دویمه مرحله: ایا L2TP کنټرول اړيکه تصدیق شوه؟

کله چې IPsec ودرېد، L2TP ډیمون ته وګورئ چې کنټرول اړيکه ټینګ حالت ته ورسیږي، ځکه PPP تر هغه دمخه نه شي پیلېدای۔ په کنټرول اړيکه کې انکار مانا دا ده چې د تونل راز د پایونو ترمنځ بېل دی، یا یو پای هغه راز غواړي چې بل هېڅکله نه لیږي۔ کارنان ډېری د shared secret نښې سره يوه ساحه ښیي، او هغه معمولاً L2TP ته نه بلکې IPsec ته اړه لري۔ هغه ډکول د تونل راز نه تنظیموي، او تشول یې نه غیر فعالوي۔

که هېڅ یوه خوا د تونل راز نه وي تنظیم کړی، دا مرحله پرېږدئ او د کنټرول اړيکې ناکامي د رسېدو ستونزه وګڼئ۔ تایید کړئ چې UDP 1701 ډیمون ته رسیږي او دواړه پایونه په ورته انکپسولیشن سره موافق دي۔ د اوروژنې هغه قاعده چې د دغو دوو شرطونو یوه لپاره لیکل شوې وي، د نیمګړې پرانیستل شوې اړيکې عام سبب دی۔

یوازې هغه غونډه چې د PPP خبرې پیلوي، د تونل مرحله واقعاً تېره کړې ده۔

درېیمه مرحله: ایا PPP حساب منکوي؟

PPP ناکامي له باندې بېله ښکاري: تونل ټینګ شوی، غونډه پیلېږي، او ډیمون د تصدیق طریقې ناکامي یا حساب انکار ثبتوي۔ په هغه پیغام کې نومول شوې طریقه ولولئ۔ PAP او CHAP د بېلو لاملونو له مخې ناکامېږي، او هغه سرور چې يوه ردوي، هغه کارن به هم رد کړي چې یوازې هغه وړاندې کوي۔

په Linux سرور کې، هغه تګلاره فایل وګورئ چې ډیمون PPP ته ورکوي، معمولاً /etc/ppp/options.xl2tpd، او تایید کړئ کومې طریقې منل کېږي او حسابونه چېرې حل کېږي۔ هغه نوم چې په RADIUS کې شته خو په ځایي راز فایل کې نه، پاک ناکامېږي او غلط پټنوم ښکاري۔ بيا وګورئ چې کارن هغه طریقه وړاندې کوي چې سرور یې مني، نه پیاوړې هغه چې سرور یې خبرې ردوي۔ د دې مرحلې د سمولو لپاره مخکې شریک شوی کلي بدلول يوه ماښام ضایع کوي او هېڅ نه بدلوي۔

کله چې غونډه بالاخره پاڅېږي، د پتو تخصیص، DNS او لارې لا نه دي کتل شوې, او هر یو په خپله طریقه چوپه ناکامېږي۔ په خپلو یادښتونو کې درې طبقې جلا وساتئ: سم کلي سره غلط حساب تل ناکامېږي، او د یوې طبقې سمول هېڅکله بله نه سمولېږي۔