Docker میں PPTP توثیق کرتا ہے مگر کوئی ٹریفک نہیں اٹھاتا

کلائنٹ توثیق کرتا ہے، PPP ایک پتے پر بات چیت کرتا ہے، اور پھر کچھ نہیں ہلتا۔ Ping ناکام ہوتا ہے، براؤزر ناکام ہوتا ہے، اور کنٹینر ہر وقت جڑا دکھائی دیتا ہے۔ یہ نمونہ روٹنگ ٹیبل کا مسئلہ نہیں ہے، کیوں کہ روٹنگ کے مسائل عام طور پر کنٹرول کنکشن بھی توڑ دیتے ہیں۔ یہ پے لوڈ کا راستہ ہے، اور PPTP میں پے لوڈ اُس پروٹوکول سے مختلف پروٹوکول ہے جو ابھی کامیاب ہوا۔

پانچ جانچیں، اُس ترتیب سے جو سب سے زیادہ وقت بچاتی ہے۔

جانچ 1: کنٹرول چینل کو پے لوڈ سے الگ کریں

PPTP TCP 1723 پر توثیق کرتا ہے اور پھر PPP پے لوڈ GRE، IP پروٹوکول 47 کے اندر لے جاتا ہے۔ GRE نہ TCP ہے نہ UDP، اس لیے کنٹرول پورٹ آگے بھیجنے والا ہر قاعدہ اُس کے بارے میں کچھ نہیں کہتا۔ 1723 گزرنے دینے والا NAT یا فائر وال پروٹوکول 47 کو بغیر شکایت گرا سکتا ہے، اور سیشن کامیابی جیسا دکھنے والے انداز میں آدھا بنا رہ جاتا ہے۔

اگر لاگ ان کام کرے اور کوئی پیکٹ واپس نہ آئے، تو پہلے GRE فرض کریں اور پھر اُسے ثابت کریں۔

جانچ 2: ہوسٹ کرنل میں مددگار کی تصدیق کریں

کنکشن ٹریکنگ مددگار کے بغیر TCP کنٹرول کنکشن کو GRE بہاؤ سے نہیں جوڑ سکتی۔ ماڈیول nf_conntrack_pptp ہے، یہ ہوسٹ کرنل میں رہتا ہے، اور کنٹینر امیج کے اندر اُسے لوڈ کرنے سے کچھ نہیں ہوتا کیوں کہ ماڈیول پورے ہوسٹ پر لاگو ہوتے ہیں۔ Docker ہوسٹ پر lsmod | grep nf_conntrack_pptp ہی جانچ ہے۔ اگر یہ نہ ہو، تو modprobe nf_conntrack_pptp اُسے چلتے کرنل کے لیے لوڈ کرتا ہے اور اگلے بوٹ کے بارے میں کچھ نہیں کہتا، اس لیے اُسے ہوسٹ کنفیگریشن میں بھی شامل کریں۔

ری بوٹ پر غائب ہونے والا ماڈیول اگلے مہینے وہی ٹکٹ بن جاتا ہے۔

جانچ 3: وہ کرنل پالیسی پڑھیں جو اُسے بند کرتی ہے

ماڈیول موجود ہونے پر بھی، 4.7 سے کرنل net.netfilter.nf_conntrack_helper کو بطور ڈیفالٹ 0 پر رکھتے ہیں، جو ہر پروٹوکول کے لیے خودکار مددگار تفویض بند کر دیتا ہے۔ یہی ڈیفالٹ وجہ ہے کہ درست طریقے سے نصب ماڈیول بھی کچھ نہیں کرتا: کوڈ موجود ہے اور پالیسی کہتی ہے کہ اُسے استعمال نہ کرو۔ sysctl net.netfilter.nf_conntrack_helper موجودہ قدر بتاتا ہے، اور رن ٹائم پر اُسے 1 پر سیٹ کرنا مددگار کو دوبارہ دستیاب کر دیتا ہے۔ اگر ڈیزائن اجازت دے تو ہوسٹ کی sysctl کنفیگریشن کے ذریعے قدر برقرار رکھیں۔

خودکار تفویض ٹریفک کو بالواسطہ توقعات بنانے دیتی ہے، اور ڈیفالٹ بدلنے کی وجہ بھی یہی ہے۔ اُسے قابلِ بھروسا ہوسٹ تک محدود کریں، یا مددگار کو نشانہ بنانے والا واضح قاعدہ استعمال کریں۔

جانچ 4: کنٹینر کا راستہ الگ سے دیکھیں

لوڈ شدہ مددگار کوئی روٹ نہیں بناتا۔ کنٹینر کو PPTP سرور تک راستہ درکار ہے، اور ہوسٹ فارورڈنگ کو دونوں سمتوں میں GRE کی اجازت دینی چاہیے: iptables -L FORWARD -v -n دکھاتا ہے کہ پروٹوکول 47 قبول ہوتا ہے یا نہیں اور کاؤنٹر ہلتے ہیں یا نہیں۔ Docker کے masquerade قواعد TCP اور UDP کا ترجمہ کرتے ہیں، پروٹوکول 47 کا نہیں، اس لیے برج کنٹینر کو واضح forward اجازت اور کچھ ہوسٹس پر اپنا ترجمہ قاعدہ درکار ہو سکتا ہے۔ یہ بھی تصدیق کریں کہ کنٹینر میں وہ PPP ڈیوائس سپورٹ ہے جو اُس کی امیج توقع کرتی ہے۔

قاعدے کا متن نہیں، کاؤنٹر پڑھیں۔ جو قاعدہ موجود ہے مگر کسی سے میل نہیں کھاتا وہ سجاوٹ ہے۔

جانچ 5: ثابت کریں کہ GRE ٹریک ہوتا ہے، پھر PPTP کا فیصلہ کریں

کلائنٹ چلتے وقت ٹریکنگ ٹیبل پڑھیں۔ قائم شدہ PPTP کنٹرول اندراج اور متعلقہ GRE اندراج کا مطلب ہے کہ مددگار بہاؤ جوڑ رہا ہے اور باقی خرابی کہیں اور ہے۔ GRE اندراج کے بغیر کنٹرول اندراج کا مطلب ہے کہ پے لوڈ گرا دیا جا رہا ہے یا ٹریک نہیں ہو رہا، جو آپ کو جانچ 2 اور 3 پر واپس لاتا ہے۔

PPTP خود پرانا ہے اور MS-CHAPv2 کمزور ہے۔ اگر سرور L2TP/IPsec، IKEv2 یا WireGuard بھی پیش کرتا ہے، تو اُن میں سے کسی ایک پر جانا اِس پوری قسم کے مسائل کو ختم کر دیتا ہے۔

جہاں PPTP کو رہنا ہی ہے، وہاں کلائنٹ کو کنٹینر کے اندر نہیں بلکہ ہوسٹ پر چلانا NAT اور فلٹرنگ کی ایک پرت ہٹا دیتا ہے، جو اکثر سستا فیصلہ ہے۔