د L2TP ډیبګ لاګ خالي دی؟ تېروتنه احتمالاً په journal کې ده

تاسو L2TP مرستندوی د ډیبګ سره پیل کوئ، ټرمینل ته ګورئ، او پر سکرین د هیڅ ګټور شی پرته ودریږي۔ دا مات شوی ډیبګ بیرغ نه دی۔ د NetworkManager L2TP اړیکه څلور همکارې پروسې دي، او یوازې ځینې یې هغه ټرمینل ته لیکي چې تاسو یې ګورئ۔ پاتې شواهد په journal کې دي، یو فلټر لرې۔

څلور پروسې، د لاګ دوه منزلونه

اړیکه د IPsec سره پیل کیږي، کوم چې د نصب له مخې libreswan یا strongSwan وي۔ بیا L2TP ډیمون، په دودیز ډول xl2tpd او په ځینو جوړښتونو کې kl2tpd، ټنل چلوي۔ په پای کې pppd دننه د تصدیق او پته ورکولو کار کوي۔

مرستندویه خدمت هغه برخې همغږي کوي او خپله پرمختګ چاپوي۔ IPsec ډیمون او pppd معمولاً د سیسټم journal له لارې راپور ورکوي، له همدې امله ټرمینل ناکامه اړیکه ښیي پداسې حال کې چې دلیل په هغه فایل کې دی چې تاسو نه یې خلاص کړی۔

دا جلاوالی هم تشریح کوي چې ولې د PSK تېروتنه او د پټنوم تېروتنه د ډیسکټاپ څخه ورته ښکاري: دواړه یو عمومي پرېکون جوړوي، او ناکام پړاو یوازې د هرې پروسې په تولید کې ښکاري۔ دلته د journal د اهمیت بشپړ دلیل همدا دی۔ په ډیسکټاپ باندې یو عمومي پیغام، د هغې شاته څلور احتمالي لیکونکي۔

یوه هڅه راټوله کړئ، بیا ترتیب ولولئ

یو ځل بیا تولید کړئ، د پیژندل شوي پروفایل او پیژندل شوي وخت سره، بیا د ټول بوټ پرځای یوه تنګه کړکۍ ولولئ۔ د تنظیماتو د بدلولو پر مهال د هڅو تکرار لاګ په داسې مخلوط بدلوي چې تشریح نشي کیدای۔

دا لارښوونې د اوسني بوټ لپاره برخه اخیستونکې پروسې غوره کوي، او ستاسو په ویش کې د پلگ ان لاره تصدیقول یې ارزښت لري:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

په یوه غوښتنه کې تکرار شوي ساحې د هغو پروسو اتحاد غوره کوي، کوم چې ترتیب په وختي ترتیب کې ساتي۔ په Debian باندې جوړ شوي سیسټم کې معادل پوښتنه dpkg -L ده؛ خبره دا ده چې مخکې لدې چې لاسي یې چلوئ، ومومئ چې مرستندوی واقعاً چېرته اوسیږي۔

بل ګام درې شرطونه ټاکي

لومړی ناکام پړاو ولولئ، بیا له هغې سره سم غوره کړئ۔ که IPsec د وړاندیز یا د سیال تصدیق ناکامي راپور کړي، ټنل هیڅکله جوړ شوی نه دی، او د PPP پټنوم بدلول مرسته نشي کولای۔

که ټنل جوړ شو او pppd د ننوتلو غوښتنه رد کړه، شریک راز مخکې سم و او د اعتبارنامې ستونزه یوه پرته پورته ده۔ که pppd د پتې په اړه خبرې وکړې او ناکامي وروسته ښکاري، دواړه کار کوي او پاتې ستونزه لارښوونه، DNS یا د سرور خپله تګلاره ده۔

دا درې څانګې نږدې هر عمومي پرېکون پوښي، او هغه دې ته په کتو ټاکل کیږي چې کومې پروسې وروستې تېروتنه ثبت کړه، نه دې ته چې کوم د تېروتنې پیغام خورا ویرونکی ښکاري۔

دا هم ارزښت لري چې مخکې لدې چې د ډیبګ تنظیم ته لاس وروړئ، تصدیق کړئ کوم IPsec backend نصب دی۔ د strongSwan لپاره لیکل شوی د لاګ اختیار هغه وخت هیڅ نه کوي چې libreswan چلیږي، او اړیکه به په هماغه ځای کې ناکامه وي څو چې تاسو هغه فایل سمولئ چې هیڅوک نه لولي۔

د ډیبګ حالت فایلونه پریږدي

اصلي ډیبګ کاري بهیر خدمت په لاسي ډول د ډیبګ بیرغ سره پیلوي، او دا حالت د اړیکې په پای کې جوړ شوي د چلولو ترتیب فایلونه په خپل ځای پریږدي۔

هغه فایلونه د تصدیق مواد لري: مخکې شریک شوی کیلي، اعتبارنامې یا دواړه۔ په چټ کړکۍ کې کاپي شوی جوړ شوی ترتیب د لاګ برخه نه ده، د اعتبارنامو افشا ده۔ مخکې لدې چې څه شریک کړئ پټې کرښې لرې کړئ، او کله چې پلټنه پای ته ورسیږي، ډایرکټري حذف کړئ۔ دوی د رازونو په توګه وګڼئ، هغه ځانګړې کرښې راوباسئ چې د راپور لپاره یې اړتیا لرئ، او بیا یې حذف کړئ، د دې پرځای چې په ټیکټ کې بشپړه ډایرکټري وڅنډئ۔

لاسي نمونه هم باید د نورمال سره همغږي شي۔ کله چې خدمت دمخه د پلگ ان مالکیت لري، د ډیبګ کاپي پیلول دوه مالکان او دواړه مخلوط کوونکی لاګ جوړوي، کوم چې د هیڅ ډیبګ تولید نه درلودو څخه بدتر دی۔

بیا نورمال مرستندوی بیا راژوندی کړئ

کله چې پلټنه پای ته ورسیږي، لاسي نمونه ودروئ، ساتل شوي د چلولو فایلونه لرې کړئ او د نورمال لارې له لارې بیا وصل شئ ترڅو بل کس د واقعیت سره سم ترتیب وګوري۔

بیا پایله په هغه طبقې کې تصدیق کړئ چې ناکامه شوه، نه د ډیسکټاپ په نښه:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

هغه ناسته چې تصدیق کوي، پته ترلاسه کوي او خپل هدف ته لارښوونه کوي، هغه پایله ده چې تاسو یې ډیبګ کوله۔ د ناکامې هڅې پر مهال غلی ټرمینل تاسو ته یوازې دا وایي چې تولید چېرته نه دی لیکل شوی۔