صرف ویب نیٹ ورک پر VPN بلاک؟ تہوں پر کام کریں

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

ثابت کریں کہ کون سی تہہ کنکشن مسترد کرتی ہے

VPN کلائنٹ سے شروع نہ کریں۔ اسی ہوسٹ کو سادہ HTTPS درخواست سے شروع کریں اور وقت کے مراحل پڑھیں، کیونکہ ناکام ہونے والا مرحلہ بتاتا ہے کہ کون سا آلہ ذمہ دار ہے:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

اب وہ سرٹیفکیٹ دیکھیں جو آپ کو واقعی ملتا ہے۔ یہ جاننے کا تیز ترین طریقہ ہے کہ آپ سرور سے بات کر رہے ہیں یا ایسے درمیانی ڈبے سے جس نے سیشن پر دوبارہ دستخط کیے:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

پراکسی سے واقف کلائنٹ پہلا پیکٹ بدلتا ہے، پالیسی نہیں

اگر نیٹ ورک تصدیق شدہ پراکسی کے ذریعے CONNECT مانگتا ہے، تو VPN کلائنٹ کو بتانا ہوگا، ورنہ وہ ایسے پتے پر ساکٹ کھولنے کی کوشش کرے گا جسے روٹ نہیں کر سکتا۔ پراکسی کو کلائنٹ سے الگ جانچیں، تاکہ ناکامی کی ایک ہی وضاحت ہو:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

پہلا حکم ثابت کرتا ہے کہ پراکسی منزل لے جائے گی۔ دوسرا کلائنٹ سے 443 پر TCP استعمال کرنے کو کہتا ہے، یہی واحد ذریعہ ہے جسے زیادہ تر صرف ویب راستے آگے بھیجتے ہیں۔ پہلا کامیاب اور دوسرا پھر بھی ناکام ہو، تو پراکسی رکاوٹ نہیں۔

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

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

پورٹ 443 قابل رسائی ہے، اجازت یافتہ نہیں

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

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

UDP عام طور پر پہلا شکار ہے، اور اس کی تصدیق کرنا بہتر ہے بجائے اندازہ لگانے کے۔ اگر TCP 443 کام کرتا ہے مگر WireGuard یا ڈیفالٹ OpenVPN کبھی مصافحہ مکمل نہیں کرتا، تو نیٹ ورک UDP گرا رہا ہے، اور کوئی کلید دوبارہ بنانا اسے نہیں بدلے گا:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

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

تصدیق کریں کہ مشین سے واقعی کیا نکلا

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

اگر SYN پیکٹ نظر آئیں اور SYN-ACK نہیں، تو رکاوٹ اوپر کی طرف ہے اور کلائنٹ بے قصور ہے۔ اگر سرور کا نہ ہونے والے پتے پر مکمل مصافحہ نظر آئے، تو آپ پراکسی یا روکنے والے سے بات کر رہے ہیں۔ اگر کچھ بھی نظر نہ آئے، تو کوئی نتیجہ نکالنے سے پہلے جانچیں کہ صحیح انٹرفیس پر کیپچر کیا۔

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

واپسی، اور وہ نوٹ جو رکھنے کے قابل ہے

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

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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