Ubuntu 22.04 پر L2TP ٹائم آؤٹ: xl2tpd ٹنل کی خرابی

ڈیسک ٹاپ ایک جاری کنکشن دکھاتا ہے، IPsec کامیابی کی اطلاع دیتا ہے، اور PPP انٹرفیس کبھی ظاہر نہیں ہوتا۔ سسٹم لاگ میں وہی ٹنل نمبر دہرایا جاتا ہے جب تک UDP 1701 پر کوشش کا وقت ختم نہ ہو جائے۔ پیشگی مشترکہ کلید یا سرور کنفیگریشن میں ترمیم کرنے سے پہلے یہ شکل پہچانیں: Ubuntu 22.04 پر یہ عام طور پر xl2tpd میں پیکیجنگ ریگریشن ہے، اور سرور ہر وقت درست تھا۔

دہرائی جانے والی لاگ جوڑی آپ کو کیا بتاتی ہے

ناکام سیشن باقاعدہ وقفوں پر دو سطریں چھاپتا ہے: ڈیمن آنے والے کنٹرول پیغام کے لیے کوئی ٹنل نہیں ڈھونڈ پاتا، پھر اسے دیے گئے کال اور ٹنل شناخت کنندگان پھینک دیتا ہے۔ بعد میں دوبارہ کوشش کا کاؤنٹر اپنی حد کو پہنچتا ہے اور کنکشن پورٹ 1701 پر وقت ختم ہونے سے بند ہو جاتا ہے۔ پتے اور شناخت کنندگان اتفاقی ہیں؛ شکل ہی اہم ہے۔ IKE مکمل ہوا، L2TP کنٹرول ٹریفک آیا، اور ڈیمن اسے پہلے سے بنائے گئے ٹنل سے منسلک نہ کر سکا۔

لہٰذا خرابی L2TP کنٹرول اور PPP کے درمیان ہے۔ راز، PPP کے اختیارات یا دور دراز سب نیٹ کے بارے میں ابھی کچھ بھی جانچا نہیں گیا۔

تصدیق کریں کہ IPsec واقعی کامیاب ہوا

دو جانچیں اسے اسناد کے مسئلے سے الگ کرتی ہیں، اور دونوں کسی بھی پیکیج تبدیلی سے پہلے ہونی چاہئیں۔

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

حالت کی آؤٹ پٹ کنکشن اور اس کی حالت کی فہرست دیتی ہے، اور قائم شدہ ٹنل کا مطلب ہے کہ پہلا اور دوسرا مرحلہ مکمل ہوا۔ گمشدہ مشترکہ کلید کے بارے میں لاگ لائن صرف راز کی طرف اشارہ کرتی ہے، اس لیے رکیں اور پہلے وہی درست کریں۔ جب IPsec قائم ہو اور L2TP ٹائم آؤٹ پھر بھی ظاہر ہو، ڈیمن ہی باقی مشتبہ ہے۔ پورے دن کی دوبارہ کوششوں کے بجائے ایک کوشش کی درست سطریں محفوظ رکھیں۔

xl2tpd کا بلڈ جانچیں، ریلیز کا نام نہیں

Ubuntu کے jammy بلڈ میں xl2tpd 1.3.16 نے لنک ٹائم آپٹیمائزیشن فعال کی، جس نے سرور کے SCCRP جواب میں ٹنل شناخت کنندہ کی پارسنگ توڑ دی۔ پھر ڈیمن اپنے ہی بنائے ہوئے ٹنل کے لیے کنٹرول پیکٹ پھینک دیتا ہے۔ ورژن سٹرنگ ڈسٹری بیوشن کے نام سے زیادہ اہم ہے۔

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

درست شدہ پیکیج 1.3.16-1ubuntu0.1 ہے، اس لیے اس لاحقے کے بغیر بلڈ درستی سے پہلے کا ہے۔ پالیسی آؤٹ پٹ دکھاتی ہے کہ اپ گریڈ کون سا امیدوار نصب کرے گا، اور ہولڈ فہرست بتاتی ہے کہ درستی کیوں نہیں آئی۔ جہاں پیکیج دستیاب ہو، اسے اپ گریڈ کریں اور ہاتھ سے فائلیں تبدیل کرنے کے بجائے عام پروفائل سے دوبارہ جڑیں۔ پرانا بلڈ نصب رہنے تک ماڈیولز دوبارہ نہ بنائیں اور راز نہ بدلیں۔

تبدیلی کے بعد PPP کی تصدیق کریں

کامیاب اپ گریڈ اسی پرت پر ثابت ہوتا ہے جو خراب تھی۔ صرف یہ نہ دیکھیں کہ آئیکن بدلا، بلکہ یہ دیکھیں کہ PPP اوپر آیا۔

ip -4 addr show ppp0
ip route | grep ppp

انٹرفیس فہرست میں مقامی اور ساتھی پتہ نظر آنا چاہیے، اور روٹ ٹیبل میں ٹنل کے سابقے ہونے چاہئیں۔ سسٹم لاگ میں ٹنل قبول ہونے اور pppd کے دونوں پتے بتانے کا اندراج ہونا چاہیے، بغیر دہرائی گئی ٹنل نہ ملنے والی سطروں کے۔ اگر PPP اوپر ہے اور ٹریفک پھر بھی ناکام ہو، تو آگے روٹنگ یا MTU دیکھیں، کیونکہ L2TP مرحلہ اپنا کام مکمل کر چکا ہے۔ کام کرنے والا پیکیج ورژن مشین کے نوٹس میں لکھیں، تاکہ مستقبل میں دوبارہ تنصیب خراب بلڈ واپس نہ لائے۔

جہاں درست شدہ پیکیج دستیاب نہیں، دستاویزی متبادل 1.3.16 یا 1.3.17 کا مقامی سورس بلڈ، kl2tpd کی طرف تبدیلی، یا پن شدہ ڈاؤن گریڈ ہیں۔ ہر ایک میں دیکھ بھال کا خرچ ہے جو لکھنے کے قابل ہے۔