پورٹ 80 اور 443 کے قواعد براؤزر کو VPN سے نہیں گزارتے

کوئی کہتا ہے کہ براؤزر سرنگ استعمال کرے، اور جواب منزل کے پورٹ 80 اور 443 سے مطابقت رکھنے والے فائر وال قاعدے کی صورت میں واپس آتا ہے۔ یہ درست لگتا ہے اور ہے نہیں۔ پورٹ کی مطابقت پیکٹوں کو ان کے نقل و حمل کے ہیڈر سے چنتی ہے، اس سے نہیں کہ کس پروگرام نے ساکٹ کھولا، اور جدید براؤزنگ TCP پر ان دو پورٹوں تک محدود نہیں۔ قاعدہ اس ٹریفک کا کچھ حصہ چھوڑ دے گا جو آپ شامل کرنا چاہتے تھے اور وہ ٹریفک پکڑ لے گا جسے آپ نے کبھی چھونے کا ارادہ نہیں کیا۔ اسے لکھنے سے پہلے طے کریں کہ تین مختلف حدوں میں سے آپ کو واقعی کون سی چاہیے۔

قاعدہ نقل و حمل کی قسم بیان کرتا ہے، کوئی ایپلیکیشن نہیں

Linux میں، منزل-پورٹ کی مطابقت TCP ہیڈر کی جانچ کرتی ہے اور اس کے اوپر کچھ نہیں۔ ان پیکٹوں کو نشان زد کرنا اور پالیسی-راستے سے گزارنا بالکل ویسے ہی کام کرتا ہے جیسے دستاویز کیا گیا ہے، اور ان طریقوں میں سے کوئی نہیں جانتا کہ پے لوڈ کا کیا مطلب ہے یا کس عمل نے اسے بھیجا۔ نشان پیکٹ سے منسلک ایک عدد ہے، ایپلیکیشن سے منسلک شناخت نہیں۔

nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100

فوراً دو نتائج آتے ہیں۔ TCP 443 سے رابطہ کرنے والا سافٹ ویئر اپ ڈیٹر براؤزر جیسا ہی سلوک پاتا ہے، جو ٹھیک ہو سکتا ہے یا اگلے اپ ڈیٹ چکر کے انتظار میں ایک رکاوٹ ہو سکتا ہے۔ اور جان بوجھ کر کسی دوسرے پورٹ پر، فرض کریں 8443، شائع شدہ ویب سروس قاعدے سے مکمل طور پر باہر رہ جاتی ہے، حالانکہ وہ اب بھی وہی ویب ٹریفک ہے جس کی صارف کو فکر تھی۔

عدد جائز منتخب کنندہ ہیں جب ضرورت واقعی ان پورٹوں کے بارے میں ہو۔ وہ افسانہ بن جاتے ہیں جب ٹکٹ میں «براؤزر» لکھا ہو اور قواعد کے مجموعے میں پورٹ کی حد نافذ کی جائے۔ یہ خلا دستاویز سازی کی باریک بینی نہیں۔ یہ اس قاعدے کے درمیان فرق ہے جس کا آپ جائزے میں دفاع کر سکتے ہیں اور اس کے درمیان جسے کوئی جانچ نہیں سکتا۔

HTTP/3 آپ کے TCP قاعدے کو خاموشی سے چھوڑ دیتا ہے

HTTP/3 QUIC پر چلتا ہے، اور QUIC UDP میں ڈھویا جاتا ہے۔ صرف TCP سے مطابقت رکھنے والا قاعدہ اسے نہیں دیکھ سکتا، اس لیے وہی براؤزر جو آپ کے آزمائشی صفحے سے گزرتا ہے بعد کی درخواست UDP پر بھیج کر سرنگ سے بچ سکتا ہے، بغیر کسی کے کوئی ترتیب بدلے۔ RFC 9114 HTTP/3 کو QUIC پر مبنی پروٹوکول بتاتا ہے، اور عام تعیناتی میں QUIC UDP استعمال کرتا ہے جس کا طے شدہ پورٹ 443 ہے۔

کوئی دیا ہوا براؤزر HTTP/3 آزمائے گا یا نہیں، یہ اس کی ترتیب، سائٹ اور اس بات پر منحصر ہے کہ پچھلی کوشش کامیاب ہوئی یا نہیں۔ اسی لیے اس پر یادداشت سے استدلال کرنا مشکل ہے۔ اس کے بجائے اوزار سے پوچھیں:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

curl کی سطر طے شدہ ورژن چھاپتی ہے، اس لیے 3 تصدیق کرتا ہے کہ UDP راستہ استعمال ہوا۔ پھر ساکٹ کی فہرست دکھاتی ہے کہ وہ کنکشن سرنگ کے انٹرفیس سے بندھا ہے یا طبعی سے۔ اگر آپ کے curl بلڈ میں HTTP/3 نہیں، تو جھنڈا خاموشی سے پیچھے ہٹنے کے بجائے بلند آواز میں ناکام ہوتا ہے، جو اس کی اپنی چھوٹی رحمت ہے۔

DNS ایک الگ فیصلہ ہے جو آپ کو کرنا ہے

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

اسے واضح طور پر طے کریں۔ اگر اندرونی نام سرنگ کے ذریعے حل ہونے چاہئیں، تو حل کنندہ اس کے اندر ہونا چاہیے، اور قواعد کے مجموعے کو اس حل کنندہ تک DNS کی اجازت دینی چاہیے اور دیگر سوالات باہر رکھنے چاہئیں۔ اگر براؤزر کسی عوامی فراہم کنندہ کی طرف DNS over HTTPS استعمال کرتا ہے، تو سوال آپ کے حل کنندہ کو مکمل طور پر بچا جاتا ہے اور پورٹ قاعدہ مدد نہیں کر سکتا۔ انتخاب کو اسی تبدیلی-ریکارڈ میں لکھیں جس میں روٹنگ قاعدہ ہے، کیونکہ اگلی ناکامی کو ڈیبگ کرنے والا دونوں کو ساتھ پڑھتا ہے۔

پھر صفحے سے نہیں، حل کنندہ سے تصدیق کریں:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

جواب نہ ملنا حل کی مسئلہ ہے، تب بھی جب براؤزر کا غلطی پیغام نیٹ ورک کو قصوروار ٹھہرائے۔ یہ دو ناکامیاں صارف کو ایک جیسی لگتی ہیں اور بالکل الگ ٹکٹ ہیں۔

تین حدیں، تین مختلف طریقے

زیادہ تر الجھن اس وقت مٹ جاتی ہے جب آپ اس حد کا نام لیتے ہیں جو آپ کو چاہیے۔ یہ ایک دوسرے کی جگہ نہیں لے سکتیں، اور سرنگ گرنے پر ہر ایک کا ناکامی کا انداز مختلف ہے۔

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

کوئی بھی قطار لاگو ہو، لکھیں کہ سرنگ گرنے پر کیا ہونا چاہیے۔ نشان پر مبنی راستہ جو انٹرفیس کے ساتھ غائب ہو جاتا ہے عام طور پر طبعی طے شدہ راستے پر واپس گرتا ہے، جو fail-open رویہ ہے۔ یہ براؤزنگ کے لیے قابل قبول اور باقی سب کے لیے ناقابل قبول ہو سکتا ہے، اور یہ فیصلہ ہے، عمل درآمد کی تفصیل نہیں۔

ان بہاؤ کی جانچ کریں جنہیں آپ ڈھکنے کا دعویٰ کرتے ہیں

قبولیت کی جانچ کو آپ کی لکھی حد کی پیروی کرنی چاہیے، سہولت والے پورٹ نمبروں کی نہیں۔ سرنگ سے گزرنا لازمی ہو ایسا ایک بہاؤ، نہ گزرنے والا دوسرا، اور وہ تیسرا جو ایسی نقل و حمل استعمال کرے جس کے بارے میں آپ نے سوچا نہیں:

ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'

راستے کی تلاش بتاتی ہے کہ منزل واقعی کون سا انٹرفیس استعمال کرتی ہے، اور یہی وہ حقیقت ہے جسے زیادہ تر رپورٹیں غلط بتاتی ہیں۔ curl کی سطر طے شدہ ورژن اور پتہ خاندان کی تصدیق کرتی ہے۔ قواعد کے مجموعے کا ڈمپ وہ قاعدہ پکڑتا ہے جو آپ نے جانچ کے دوران شامل کیا اور محدود کرنا بھول گئے، اور اسی طرح عارضی نشان مستقل fail-open روٹنگ بن جاتا ہے۔

تینوں آؤٹ پٹ وقت کی مہر کے ساتھ درج کریں اور تبدیلی کے ساتھ رکھیں۔ جب بعد میں کوئی بتائے کہ «VPN نے انٹرانیٹ توڑ دیا»، تو مطلوبہ اور نافذ شدہ حد کا فرق اسی ریکارڈ میں نظر آئے گا، اور درستی قاعدہ بدلنا ہوگی، بحث نہیں۔