Linux پر IPsec کے بغیر L2TP: xl2tpd, pppd اور NAT

سادہ L2TP ایک لفافے میں PPP ہے، اور اس کے سوا کچھ نہیں۔ یہ آپ کے فریم لے کر چلتا ہے؛ انہیں خفیہ نہیں کرتا اور یہ ثابت نہیں کرتا کہ دوسرے سرے پر کون بیٹھا ہے، اسی لیے تقریباً ہر تعیناتی اس کے نیچے IPsec رکھتی ہے۔ ننگا ورژن چلانے کی دیانت دار وجوہات اب بھی موجود ہیں: کوئی لیب بینچ، کوئی منتقلی کا مرحلہ، یا ایسی لنک جو پہلے ہی کسی دوسرے محفوظ راستے کے اندر ہو۔

اگر آپ پھر بھی آگے بڑھیں تو وہ انتباہ ڈیزائن نوٹ میں لکھیں اور وہیں رہنے دیں۔ آگے جو ہے وہ Debian اور RHEL خاندان کے ہوسٹس پر میرا استعمال کردہ آپریشنل راستہ ہے: کون سی فائل کس کی ذمہ دار ہے، وہ MTU جو کلاسک رکاوٹ کو روکتا ہے، اور وہ فارورڈنگ قواعد جو سرنگ کو قابلِ قدر بناتے ہیں۔

تین فائلیں کام بانٹتی ہیں

xl2tpd کنٹرول کنکشن ختم کرتا ہے اور ہر سیشن PPP ڈیمون کے حوالے کرتا ہے، اس لیے ترتیب دو پروگراموں میں بٹی ہوئی ہے جو کبھی ایک دوسرے کی فائلیں نہیں پڑھتے۔ سننے والا /etc/xl2tpd/xl2tpd.conf میں، [lns default] حصے کے اندر رہتا ہے، جو پتوں کے تالاب کو ip range سے، سرور کے سرے کو local ip سے اور PPP کو حوالے کرنے کو pppoptfile سے نام دیتا ہے۔ require authentication = yes آن کریں، length bit اور flow bit فعال رکھیں، اور ایسا تالاب چنیں جو ہوسٹ پر اور کچھ استعمال نہ کر رہا ہو۔

PPP پالیسی اُس فائل کی ہے جس کا نام وہ اختیار بتاتا ہے، عام طور پر /etc/ppp/options.xl2tpd: auth، pap، chap اور mschap کے لیے انکار، require-mschap-v2، 1460 کا MTU اور MRU، اور وہ DNS پتہ جہاں لنک اٹھنے کے بعد کلائنٹ پہنچ سکے۔ اسناد پھر تیسری فائل ہیں، /etc/ppp/chap-secrets، جہاں دوسرا خانہ LNS حصے کے نام سے میل کھانا چاہیے اور چوتھا خانہ تالاب سے کوئی مخصوص پتہ پن کر سکتا ہے۔

سرنگ کیوں جڑتی ہے اور پھر رک جاتی ہے

1500 بائٹ کا Ethernet فریم ایسے راستے میں نہیں سماتا جو پہلے ہی اپنے ہیڈروں پر بائٹ خرچ کر رہا ہو۔ بیرونی IPv4 ہیڈر 20 لیتا ہے، UDP 8، اور L2TP ہیڈر تقریباً 12، جس سے PPP اور اس کے پے لوڈ کے لیے 1460 بچتا ہے۔ PPP میں یہی چھوٹا عدد اعلان کرنا بڑے پیکٹوں کو ٹکڑوں میں بٹنے یا درمیان میں کہیں خاموشی سے گرنے سے روکتا ہے۔

علامت ایسی سرنگ ہے جو اصل ٹریفک آنے تک صحت مند دکھائی دیتی ہے: پنگ اور کنٹرول پیغامات گزر جاتے ہیں، فائل کی نقل رک جاتی ہے، لاگ میں کوئی چیز اس کی وضاحت نہیں کرتی۔ دونوں سروں پر MTU اور MRU ساتھ ساتھ کم کریں۔ صرف کلائنٹ درست کرنے سے سخت رکاوٹ عام طور پر وقفے وقفے سے آنے والی رکاوٹ بن جاتی ہے، جس کی تشخیص زیادہ مشکل ہے۔

ایک پورٹ دو گفتگوؤں کو لے چلتی ہے

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

بالکل اسی ترتیب میں کیپچر پڑھنے سے پتہ چلتا ہے کون سا مرحلہ ناکام ہوا، اور PPP تصدیق کی ناکامی xl2tpd میں ترمیم سے درست نہیں ہوتی۔ مشترکہ پورٹ ایک اور عام ناکامی کی وضاحت کرتی ہے: جو قاعدہ بہاؤ کے صرف پہلے پیکٹوں کی اجازت دیتا ہے وہ سیشن قائم ہونے دیتا ہے اور پھر منتقلی روک دیتا ہے۔ پوری گفتگو کے لیے 1701، دونوں سمتوں میں اجازت دیں۔

سرنگ کو کارآمد بنانا: فارورڈنگ اور NAT

سیشن بذاتِ خود صرف سرور تک پہنچتا ہے۔ کلائنٹ کی انٹرنیٹ رسائی کے لیے فارورڈنگ، اپ لنک پر تالاب کے لیے NAT قاعدہ، اور ایسا DNS چاہیے جسے لنک اٹھنے کے بعد کلائنٹ واقعی پوچھ سکے۔ تالاب کو LAN کی حد سے باہر بھی رہنا چاہیے، ورنہ کلائنٹس کو بھیجے گئے جوابات سرنگ میں واپس دھکیلنے کے بجائے مقامی طور پر پہنچا دیے جاتے ہیں۔

سرور پر sysctl -w net.ipv4.ip_forward=1 سے فارورڈنگ آن کریں، iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE سے تالاب کا ترجمہ کریں، پھر -i ppp0 -o eth0 کے لیے FORWARD قاعدے سے باہر جانے والی سرنگ ٹریفک اور آئینے کے قاعدے کے ساتھ -m state --state RELATED,ESTABLISHED سے واپس آنے والی ٹریفک قبول کریں۔ ان قواعد کو دوبارہ شروع ہونے کے دوران بھی برقرار رکھیں، کیوں کہ ان کے بغیر واپس آنے والا سرور بالکل خراب L2TP ترتیب جیسا دکھائی دیتا ہے۔

سرور کے اپنے LAN تک پہنچنا دوسرا کام ہے: LAN راؤٹر پر تالاب کے لیے واپسی کا راستہ شامل کریں، یا سرور پر proxy ARP چلائیں۔ جب LAN کے اندر کی کوئی چیز کلائنٹس کو براہِ راست مخاطب کرنے پر مجبور ہو تو انہیں NAT کے پیچھے چھپانا صرف بعد کے لیے دوسرا ڈیبگ سیشن طے کرنا ہے۔

ننگا اسٹیک کیا نہیں کرتا، اور کیسے جانچیں

اس اسٹیک کا کوئی حصہ PPP فریموں کو خفیہ نہیں کرتا، اور اس میں کچھ بھی دور کے سرے کو اُس سرور کے طور پر تصدیق نہیں کرتا جو آپ نے واقعی منتخب کیا تھا۔ MS-CHAPv2 صرف دیکھنے والے سامع سے اسناد کے تبادلے کی حفاظت کرتا ہے، پھر بھی راستے میں بیٹھا حملہ آور سیشن میں مداخلت کر سکتا ہے۔ Windows کا مقامی کلائنٹ L2TP صرف IPsec کے ساتھ دیتا ہے، اس لیے Linux، راؤٹر فرم ویئر اور فریقِ ثالث کے کلائنٹس کو اپنا ہم منصب سمجھیں۔ ننگی ترتیب کو تشخیص کا زینہ سمجھیں، کبھی رکنے کی جگہ نہیں۔

مقررہ ترتیب میں جانچیں: xl2tpd -D کو سامنے چلائیں، PPP مرحلے کے لیے جرنل دیکھیں، دونوں سروں پر ip addr سے دیا گیا پتہ پڑھیں، پھر سیشن اٹھنے کے بعد ڈیٹا بہنے کی تصدیق کے لیے UDP 1701 کیپچر کریں۔ اگر چاروں میل کھائیں اور ٹریفک پھر بھی ناکام ہو، تو قصور راؤٹنگ، NAT یا MTU میں ہے، خود L2TP میں نہیں۔