L2TP/IPsec کا PSK مسترد: پہلے ڈائیلاگ، پھر فائلیں

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

نیچے کا راستہ کلید کو خانے سے فائل تک لے جاتا ہے، اور یہی ترتیب بتاتی ہے کہ وہ کہاں گم ہوئی۔ یہ اُس مشین پر کریں جو ناکام ہوتی ہے، نہ کہ اُس پر جو چلتی ہے، کیونکہ اِن دو مشینوں کا فرق عموماً فائلوں کی ترتیب ہوتا ہے، کلید نہیں۔

ڈائیلاگ سے شروع کریں، مگر خانے پر بھروسا نہ کریں

کنکشن کا IPsec ٹیب کھولیں اور کلید چسپاں کرنے کے بجائے دوبارہ ٹائپ کریں۔ چیٹ پیغام، PDF یا پاس ورڈ مینیجر سے نقل کی گئی کلید کے آخر میں ایسا لائن بریک آ سکتا ہے جو خانہ نہیں دکھاتا، اور نظر آنے والے حروف پھر بھی درست لگتے ہیں۔

پاس ورڈ دکھانے والے کنٹرول پر کلک کریں اور سٹرنگ کے آخر کو دیکھیں، درمیان کو نہیں۔ اگر کرسر متن کے نیچے خالی سطر چھوڑ دے تو اسے مٹا دیں اور آخری حرف دوبارہ ٹائپ کریں۔ یہی ایک اصلاح ایسی رپورٹوں کا حیران کن حصہ حل کر دیتی ہے، اور کسی بھی لاگ کے پڑھنے سے کم خرچ ہے۔

اگر کلید ایسے ٹکٹ نظام سے آئی ہے جو لمبی سطریں موڑتا ہے تو اُس ذریعے سے مانگیں جو نہیں موڑتا۔ دو سٹرنگیں ساتھ ساتھ دیکھنے کے بجائے لمبائی منتظم سے موازنہ کریں؛ موڑ کے مقام پر گمشدہ حرف متناسب فونٹ میں نظر نہیں آتا۔

کلید کا پیچھا /etc/ipsec.d کے اندر کریں

پلگ ان PSK کو IPsec ڈیمن کو کبھی کمانڈ لائن پر دلیل کے طور پر نہیں دیتا۔ اس کے بجائے قدر کو سیکرٹ فائل میں رکھتا ہے اور بندوبست کرتا ہے کہ ڈیمن وہ فائل شامل کرے، اگر نہ ہو تو /etc/ipsec.secrets میں include سطر بڑھاتا ہے۔ ڈائیلاگ جو تھامے ہوئے ہے وہ اُس بنائی گئی فائل کا ان پٹ ہے، زیرِ استعمال قدر نہیں۔

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

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

پلگ ان کی پرانی ریلیز ہر کنکشن کے لیے ایک فائل لکھتی تھیں، جو کنکشن کے UUID کے نام پر ہوتی، مثلاً /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets۔ ایپلٹ میں پروفائل مٹانے سے وہ فائل قابلِ اعتماد طریقے سے نہیں مٹتی۔ اگر پچھلے سرور کی پرانی فائل اب بھی ڈسک پر ہو اور اب بھی شامل ہو، تو ڈیمن ایسا راز چن سکتا ہے جو اُس پروفائل کا ہو جو آپ اب استعمال نہیں کرتے، اور نظر آنے والا خانہ درست ہونے کے باوجود کنکشن ناکام ہو جاتا ہے۔

سمجھیں کہ 1.2.12 کی تبدیلی نے اپ گریڈ کے ساتھ کیا کیا

پلگ ان ورژن 1.2.12 نے فی کنکشن سیکرٹ فائلوں کی جگہ ایک مشترکہ فائل رکھ دی، /etc/ipsec.d/ipsec.nm-l2tp.secrets۔ اپ گریڈ پرانی UUID والی فائلیں صاف نہیں کرتا، اور موجودہ include /etc/ipsec.d/*.secrets سطر اُنہیں اب بھی شامل کرتی ہے۔ ورژن 1.2.16 نے طے شدہ تجاویز کی برتاؤ بدلی، رازوں کی ترتیب نہیں۔

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

اُن حروف کو الگ کریں جو ذخیرہ کاری کی صورت نہیں رکھ سکتی

مشترکہ سیکرٹ سٹرنگ کے بارے میں strongSwan کی دستاویز کہتی ہے کہ قدر میں نئی سطر یا دوہرا اقتباس کا حرف نہیں ہو سکتا۔ دستاویز سے چسپاں کی گئی کلید عام ڈائیلاگ میں بغیر کسی نظر آنے والے فرق کے اِن دونوں میں سے کوئی بھی لیے ہو سکتی ہے۔

1.2.12 سے محفوظ قدر سادہ متن نہیں ہے۔ پلگ ان فائل تک پہنچنے سے پہلے PSK کو base64 میں انکوڈ کرتا ہے، اور ریلیز نوٹس اِسی انکوڈنگ کو وجہ بتاتے ہیں کہ دوہرا اقتباس اب کلید میں قابلِ قبول ہے۔ چنانچہ خانے میں ٹائپ کیا گیا اقتباس قابلِ اظہار ہے؛ ہر کنٹرول حرف کے لیے یہ درست نہیں۔

لمبائی ایک اور قید ہے۔ L2TP/IPsec سافٹ ویئر میں کوئی عالمگیر کم از کم لاگو نہیں ہوتا: کچھ کلائنٹ بیس حروف سے چھوٹی کلیدیں قبول کرتے ہیں اور کچھ گیٹ وے کم از کم لازم ٹھہراتے ہیں۔ اگر چھوٹی کلید مسترد ہو تو وہ قاعدہ سرور کی پالیسی یا اُس کلائنٹ کی توثیق کا ہوتا ہے، اور مقامی طور پر کچھ بڑھانے سے وہ نہیں بدلے گا۔

پڑھیں کہ توثیق کی کون سی پرت ناکام ہوئی

پہلے ipsec --version چلائیں، کیونکہ strongSwan اور Libreswan مختلف فائل نام اور نحو استعمال کرتے ہیں، اور ایک کے لیے دیا گیا مشورہ دوسرے کو نقصان پہنچا سکتا ہے۔ پھر کلائنٹ کے پیغام یا ڈیمن لاگ سے ناکامی کا مرحلہ پڑھیں: قبل از اشتراک کلید کی شکایت مسترد شدہ صارف نام اور پاس ورڈ سے مختلف واقعہ ہے۔

PSK سرنگ کے دونوں سروں کی توثیق کرتا ہے۔ صارف نام اور پاس ورڈ L2TP کے اندر موجود شخص کی توثیق کرتے ہیں، اور IPsec رشتہ اٹھنے کے بعد PPP اِنہیں سنبھالتا ہے۔ درست PSK غلط اکاؤنٹ کے ساتھ بھی ناکام ہوتا ہے، اور اکاؤنٹ بدلنے سے ایسی کلید درست نہیں ہوگی جو ڈیمن نے کبھی ٹھیک سے نہ پڑھی ہو۔

ٹکٹ بند کرتے وقت چاروں باتیں لکھیں: پلگ ان ورژن، زیرِ استعمال سیکرٹ فائل، کلید دوبارہ ٹائپ ہوئی یا چسپاں، اور خرابی میں بتائی گئی پرت۔ تب یہ راستہ بعد میں دہرانے والا کوئی بھی سیدھا کام کرنے والی اور ناکام مشین کے فرق پر جا سکے گا۔