OpenVPN اور HTTPS پورٹ 443 پر: سننے والا کس کا ہے؟
TCP اور UDP 443 الگ ساکٹ ہیں۔ ایک TCP سننے والے کو بانٹنے کے لیے مالک درکار ہے، اور OpenVPN کی پورٹ شیئرنگ ایک تنگ انتظام ہے، پراکسی کی چال نہیں۔
دو خدمات بغیر کبھی مقابلہ کیے دونوں پورٹ 443 پر جواب دے سکتی ہیں، کیونکہ سننے والا صرف نمبر سے نہیں بلکہ ترسیل، پتہ اور پورٹ مل کر طے ہوتا ہے۔ ایک ہی مشین پر ویب سرور اور OpenVPN رکھیں، اور پہلے جواب دینے کے لائق واحد سوال یہ ہے کہ ہر عمل کرنل سے کون سا ساکٹ مانگتا ہے۔ ترتیب میں ترمیم سے پہلے وہ فہرست لکھ لیں، اور «پتہ پہلے ہی استعمال میں ہے» کی زیادہ تر غلطیاں خود ہی واضح ہو جائیں گی۔ فہرست کے بعد سب کچھ UDP سننے والے، مشترکہ TCP ساکٹ یا پروٹوکول کے مطابق راستہ دکھانے والے سامنے والے حصے کے درمیان انتخاب ہے۔
ہر عمل جو ساکٹ مانگتا ہے وہیں سے شروع کریں
bind اسی ثلاثی پر کامیاب یا ناکام ہوتا ہے، اس لیے دو ڈیمن صرف اسی وقت ٹکراتے ہیں جب تینوں حصے مل جائیں۔ اسی لیے TCP 443 پر ویب سائٹ UDP 443 پر OpenVPN سننے والے کے ساتھ غیر معینہ مدت تک رہتی ہے، اور اسی لیے ان میں سے ایک کو اسی ہوسٹ کے دوسرے مقامی پتے پر منتقل کرنا بھی بحث ختم کر دیتا ہے۔ زندہ سننے والے پڑھیں، وہ فائلیں نہیں جو انہیں بنانی چاہیے تھیں، کیونکہ پرانا include یا بھولی ہوئی unit فائل آپ کی یاد والی ترمیم سے زیادہ عرصہ رہتی ہے۔
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root کے طور پر ss -lntup چلائیں اور 443 کا ذکر کرنے والی ہر سطر، IPv6 اندراجات سمیت پڑھیں۔ عام طور پر وائلڈ کارڈ v6 سننے والا v4 ٹریفک بھی قبول کرتا ہے، اور اسی طرح بھولا ہوا سننے والا آپ کی ذمہ دار سمجھی گئی فائل بدلنے کے بعد بھی پورٹ پر قبضہ رکھتا ہے۔ اگر عمل کا نام آپ کو حیران کرے تو کچھ بھی چھونے سے پہلے ss -lntup 'sport = :443' سے آؤٹ پٹ محدود کریں۔
جب نیٹ ورک اجازت دے تو سرنگ کو UDP پر لے جائیں
UDP سننے والا تصادم کو مکمل طور پر بچاتا ہے اور عموماً سب سے مختصر مرمت ہے، کیونکہ کوئی ساکٹ مشترک نہیں ہوتا اور راستے میں کوئی اضافی مصنوع نہیں آتی۔ لیکن یہ مفت نہیں۔ کچھ کلائنٹ نیٹ ورک reset بھیجے بغیر UDP 443 گرا دیتے ہیں، اس لیے سرنگ bind میں ناکام ہونے کے بجائے قائم ہونا بند کر دیتی ہے، اور صارف پڑھنے کے لائق کسی خرابی کے بغیر VPN بند ہونے کی اطلاع دیتا ہے۔ UDP سننے والا ویب پرت کی دوبارہ شروعات بھی برداشت کرتا ہے، جو ایسی مشین پر اہم ہے جس کی سائٹ بار بار دوبارہ تعینات ہوتی ہے۔ اسی نیٹ ورک سے جانچیں جہاں صارفین بیٹھے ہیں، کیونکہ سرور پر shell صرف یہ ثابت کرتا ہے کہ سرور خود تک پہنچ سکتا ہے۔
سرور ترتیب اور کلائنٹ پروفائل میں ترسیل ایک ساتھ بدلیں۔ جو پروفائل ابھی بھی TCP مانگتی ہے وہ صرف UDP سننے والے کے سامنے دوبارہ جڑنے کے چکر میں گھومے گی، اور دو فائلوں کے موازنے تک یہ نیٹ ورک خرابی جیسی لگتی ہے۔
VPN عمل کو TCP 443 کا مالک بننے دیں اور باقی آگے بھیجیں
TCP سرور موڈ میں Community OpenVPN آنے والے کنکشن کے پہلے بائٹ پڑھتا ہے اور جو اس کا اپنا پروٹوکول نہیں وہ سب HTTPS بیک اینڈ کو بھیجتا ہے، port-share ہدایت اسی کے لیے ہے۔ بیک اینڈ TLS فعال رکھنے والا عام ویب سرور ہے، جسے اس ہدایت میں URL سے نہیں بلکہ ہوسٹ اور پورٹ سے نام دیا جاتا ہے۔
port-share 10.0.0.5 8080
جس مشین میں سائٹ کا دوسرا نجی پتہ ہو، وہاں وہ سطر غیر VPN ٹریفک 10.0.0.5:8080 پر بھیجتی ہے، اس لیے HTTPS مجازی ہوسٹ وہیں بائنڈ ہونا چاہیے اور فائر وال کو مقامی چھلانگ کی اجازت دینی چاہیے۔ ویب سرور کو TLS خود ختم کرنا ہوگا، کیونکہ آنے والے بائٹ براؤزر کا اصل ہینڈ شیک ہیں اور درمیان میں کسی نے انہیں ڈکرپٹ نہیں کیا۔ ہدایت کو عام HTTP سننے والے کی طرف موڑیں تو براؤزر کو غلط طریقہ کی خرابی ملے گی، جو بیک اینڈ کے غلط جگہ ہونے کے بجائے ٹوٹی سائٹ جیسی پڑھی جاتی ہے۔ ہدایت صرف TCP سرور موڈ میں موجود ہے، اور UDP سننے والے کے پاس جانچنے کے لیے کوئی اسٹریم نہیں۔
چونکہ VPN عمل ہر کنکشن قبول کرتا ہے، ویب ایپلیکیشن آگے بھیجی گئی درخواست کو مہمان سے نہیں بلکہ ہوسٹ کے اپنے پتوں میں سے کسی ایک سے آتی دیکھتی ہے۔ جسے اصل کلائنٹ پتہ درکار ہو وہ بیک اینڈ میں PROXY پروٹوکول کی معاونت یا اسے شامل کرنے والے سامنے والے حصے پر منحصر ہے۔ بیک اینڈ کو دوسرے مقامی پتے پر منتقل کرنا مہمان کا پتہ واپس نہیں لاتا؛ یہ صرف بدلتا ہے کہ سائٹ ہوسٹ کے کون سے پتے درج کرتی ہے۔ تجزیاتی رپورٹ کے سوال اٹھانے سے پہلے یہ حد تعیناتی نوٹس میں لکھیں۔
ریورس پراکسی غلط اوزار ہے؛ لیئر-چار راؤٹر نہیں
HTTP ریورس پراکسی درخواستیں پڑھنے کے لیے TLS ختم کرتا ہے، یعنی یہ OpenVPN اسٹریم کو بغیر چھوئے گزر نہیں سکتا۔ SNI یا پہلے پیکٹ کے معائنے کے مطابق آگے بھیجنے والا لیئر-چار راؤٹر دونوں کے سامنے کھڑا ہو سکتا ہے، بشرطیکہ وہ اس سیشن کو ختم نہ کرے جس پر VPN منحصر ہے۔ دونوں آلات نقشے میں ایک جیسے دکھتے ہیں اور ساکٹ پر بالکل مختلف برتاؤ کرتے ہیں۔
تجارتی Access Server اپنی پورٹ شیئرنگ ترتیبات لے کر آتا ہے، اور وہ کمیونٹی ہدایت سے ایک کے بدلے ایک نہیں ملتیں۔ دوسرے کے لیے لکھی گئی گائیڈ اپنانے سے پہلے مصنوع اور ورژن پہچانیں۔ خاموشی سے نظر انداز کی گئی نقل شدہ ترتیب ترتیب نہ ہونے سے بھی بدتر ہے، کیونکہ اس کے بعد بھی سننے والوں کی فہرست قابل اعتماد دکھتی ہے۔
ویب سائٹ اور سرنگ کو دو الگ راستوں کے طور پر جانچیں
سائٹ لوڈ کریں اور سرنگ جوڑیں، پھر سننے والوں کی فہرست دوبارہ پڑھیں کہ اب 443 کا مالک کون سا عمل ہے۔ لوڈ ہونے والا صفحہ VPN کے بارے میں کچھ ثابت نہیں کرتا، اور جڑنے والی سرنگ سائٹ کے بارے میں کچھ ثابت نہیں کرتی، اگرچہ دونوں ایک ہی نمبر استعمال کرتے ہیں۔ نیچے دیے گئے تین احکام بالترتیب مشترکہ ساکٹ، ویب راستہ اور VPN سروس جانچتے ہیں۔
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
اسی لمحے کے لیے بیک اینڈ کے رسائی لاگ میں کلائنٹ پتے کا VPN لاگ والے پتے سے موازنہ کریں۔ اگر سائٹ ہر مہمان کو ہوسٹ خود کے طور پر درج کرتی ہے تو آگے بھیجنا کام کرتا ہے اور پتے کی سنبھال نہیں۔ اگر دونوں لاگ خاموش رہیں تو سامنے والے حصے نے کبھی کنکشن نہیں سونپا۔ بہرحال، ساکٹ کون قبول کرتا ہے یہ سننے والوں کی فہرست طے کرتی ہے، اور دوسری فائل بدلنے سے پہلے یہی حقیقت تصدیق کرنی ہے۔
وہ سننے والوں کا نقشہ ترتیب کے پاس چھوڑ دیں تاکہ 443 کو چھونے والا اگلا شخص جان سکے کہ کون سا عمل قبول کرتا ہے اور دوسرا پروٹوکول کہاں گیا۔ ترمیم کا مقصد کیا تھا اس پر بھروسا کرنے کے بجائے تبدیلی کے بعد ملکیت کی تصدیق کریں۔