VPN ٹنل کبھی جڑتا نہیں: پیکٹ دراصل کہاں رکتے ہیں

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

ثابت کریں کہ ٹریفک کہاں رکتا ہے

ایک ہی وقت میں کلائنٹ کے آؤٹ باؤنڈ انٹرفیس اور سرور پر کیپچر کریں۔ جو گیا اس کا جو آیا سے موازنہ کریں، اور نوٹ کریں کہ فرق کس سمت میں نظر آتا ہے۔

سرور پر کچھ نہ ہونے کا مطلب ہے کہ راستہ یا پہلا NAT ٹریفک گرا رہا ہے، جبکہ بغیر جواب آنے والے آمد سرور پر فائر وال یا غیر موجود واپسی راستے کی طرف اشارہ کرتے ہیں۔ جو راؤٹر اکثر ٹنل ختم کرتا ہے وہ عموماً کوئی مفید لاگ نہیں رکھتا، اس لیے کیپچر ہی ریکارڈ بن جاتا ہے۔ منزل پورٹ اور پروٹوکول نمبر لکھ لیں، کیونکہ دونوں ناکامیاں کلائنٹ ڈائیلاگ میں یکساں دکھائی دیتی ہیں۔

پروٹوکول 47 کے بغیر PPTP مرتا ہے

PPTP کنٹرول TCP 1723 پر اور ڈیٹا GRE کے اندر لے جاتا ہے، جو پورٹ نمبر نہیں بلکہ IP پروٹوکول 47 ہے۔ صرف 1723 فارورڈ کرنے سے روایتی نتیجہ آتا ہے: کنکشن تصدیق ہوتا ہے اور پھر خاموش ہو جاتا ہے، کیونکہ پے لوڈ لے جانے والے پروٹوکول کے لیے کوئی قاعدہ نہیں ہے۔ کلائنٹ اسے مسترد شدہ پاس ورڈ سے الگ نہیں کر سکتا، اس لیے کیپچر کنفیگریشن تبدیلیوں سے پہلے ہونا چاہیے۔

پاس تھرو آنے والے فارورڈ کی مخالف سمت میں چلتا ہے، اور فرم ویئر اکثر دونوں کے لیے ایک ہی لیبل استعمال کرتا ہے، جو سب کو الجھانے کے لیے کافی ہے۔ لینکس کلائنٹ پر مقامی فائر وال راؤٹر کے شامل ہونے سے بہت پہلے GRE گرا سکتا ہے، اس لیے پروٹوکول 47 کو اپنا قاعدہ چاہیے اور conntrack مددگار لوڈ ہونا چاہیے۔ ابونٹو کا ufw یہ قواعد before فائل میں رکھتا ہے، کیونکہ عام allow قواعد پروٹوکول نمبر بیان نہیں کر سکتے۔ بعد میں مشین کو ری بوٹ کرنے کے بجائے فائر وال دوبارہ لوڈ کریں۔

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

دو NAT کے پیچھے L2TP اور IPsec

L2TP IPsec کے اندر کلید کے تبادلے کے لیے UDP 500، NAT پہچانے جانے پر UDP 4500، اور پروٹوکول 50 کے طور پر ESP چاہتا ہے۔ ان میں سے ہر ایک الگ فلٹر ہوتا ہے، اس لیے ایک کی اجازت دینے والا قاعدہ باقی دو کے بارے میں کچھ ثابت نہیں کرتا۔ سلسلے میں دو راؤٹر ہر پیکٹ کا دو بار ترجمہ کرتے ہیں، اور سرے اب اس بات پر متفق نہیں کہ کیا طے ہوا تھا۔

بیرونی موڈیم کو برج کریں، یا اندرونی راؤٹر پر NAT بند کریں، تاکہ عوامی پتہ ٹنل ختم کرنے والے آلے تک پہنچے۔ جہاں دونوں ممکن نہ ہوں، ٹنل ڈبل NAT کی حد کے اندر سے شروع ہونی چاہیے، وہاں ختم نہیں۔

کیریئر نیٹ ورک اور پتوں کی شراکت

WAN پتہ 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16 یا 100.64.0.0/10 کے اندر ہونے کا مطلب ہے کہ راؤٹر کے پاس عوامی پتہ نہیں اور انٹرنیٹ سے کوئی آنے والا فارورڈ اس تک نہیں پہنچ سکتا۔ کیریئر درجے کا NAT ان پروٹوکولز کو بھی فلٹر کرتا ہے جن کی توقع نہیں، اور موبائل لنکس پر GRE اکثر شکار ہوتا ہے۔ راؤٹر پر ہی WAN پتے کا موازنہ کریں، اس پتے سے نہیں جو کوئی تلاش سائٹ اس کے پیچھے والے کلائنٹ کے لیے بتاتی ہے۔

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

پورٹ بند کرنے سے پہلے سننے والوں کی فہرست پڑھیں

پریشان کن پورٹ اسکین اکثر صرف وہ فیچر سیٹ ہوتا ہے جو فعال حالت میں آتا ہے۔ سننے والوں کی فہرست بنائیں، ہر ساکٹ کو کسی فیچر سے جوڑیں، پھر پورٹ بلاک کرنے کے بجائے فیچر بند کریں، تاکہ دونوں نظریے الگ نہ ہوں۔

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther کے ڈیفالٹ اچھی مثال ہیں: TCP 443، 992 اور 5555، ساتھ ہی L2TP/IPsec اور DNS ٹنل فیچر اپنے ساکٹ شامل کرتے ہیں۔ ان فیچرز کو بند کرنا سننے والوں کو چھپانے کے بجائے ہٹا دیتا ہے، اور بیرونی ہوسٹ سے جانچ بتاتی ہے کہ کیریئر پورٹ کو آنے دیتا ہے یا نہیں۔ مقامی طور پر جواب دینے والا سننے والا اوپر کی طرف بند ہو سکتا ہے، اس لیے راؤٹر کے اپنے WAN پتے کا موازنہ بیرونی سروس کے بتائے سے کریں۔