آپ کے VPN ٹنل کا پتہ اندرونی پورٹ کیوں نہیں کھولتا
ٹنل کا پتہ آپ کے کلائنٹ کی شناخت اُن ساتھیوں کے سامنے کرتا ہے جو اُس تک روٹ کر سکتے ہیں، اور کبھی سننے والا پیدا نہیں کرتا۔ بائنڈنگ، واپسی کا راستہ اور پھر پالیسی جانچیں۔
دفتر کے VPN سے جڑیں، پورٹ 8443 پر ایک چھوٹی سروس شروع کریں، ٹنل کا پتہ کسی ساتھی کو بھیجیں اور دیکھیں کہ کنکشن ناکام ہو جاتا ہے جبکہ کلائنٹ اب بھی جڑا ہونے کی اطلاع دیتا ہے۔ ٹنل میں کچھ بھی خراب نہیں: پتہ دیا جا چکا ہے، سیشن فعال ہے، اور جواب لے جانے والے پیکٹ کبھی قبول نہیں کیے جاتے۔ نیچے دی گئی تین جانچیں ترتیب سے کریں اور جہاں ناکامی ہو وہیں رکیں، کیونکہ ہر ایک کا حل مختلف ہے اور ان میں سے صرف ایک کا تعلق VPN سے ہے۔
اس بات سے شروع کریں کہ ساکٹ واقعی کہاں بندھا ہے
کسی چیز کے روٹ ہونے سے پہلے، کسی کو ایسے پتے پر سننا چاہیے جہاں کال کرنے والا پہنچ سکے۔ ڈویلپمنٹ سرور عام مجرم ہیں، کیونکہ ان میں سے بہت سے بطور ڈیفالٹ loopback پر بندھتے ہیں اور صرف اسی مشین سے آنے والے کنکشن قبول کرتے ہیں۔ ٹنل کا پتہ اس بائنڈنگ کو نہیں بدلتا، اور آپریٹنگ سسٹم VPN کے شامل ہونے سے بہت پہلے کنکشن رد کر دے گا۔
ss -ltnp | grep 8443
netstat -ano | findstr 8443حالت نہیں، مقامی پتے کا کالم پڑھیں۔ 127.0.0.1:8443 کا مطلب صرف loopback ہے، اور حل 0.0.0.0 یا خود ٹنل کے پتے پر بائنڈ کرنا ہے۔ 0.0.0.0:8443 ہر انٹرفیس پر قبول کرتا ہے، جو اس سے زیادہ وسیع ہے جتنا زیادہ تر لوگ سوچتے ہیں جب مشین کا عوامی پتہ بھی ہو؛ 10.64.7.15:8443 تنگ ورژن ہے جو صرف وہاں سنتا ہے جہاں ساتھی پہنچ سکے۔ اسی آؤٹ پٹ میں پروسیس کا نام بھی دیکھیں، کیونکہ پچھلے ٹیسٹ سے بچا ہوا کوئی انسٹانس ایک عام وجہ ہے کہ پورٹ کھلا دکھائی دے اور غلط مواد کے ساتھ جواب دے۔
پھر پوچھیں کہ کیا کوئی اس پتے تک روٹ کر سکتا ہے
ٹنل کے پتے کا مطلب صرف اُن ساتھیوں کے لیے ہے جو اُس سابقے کو ٹنل میں بھیجنے کے لیے ترتیب دیے گئے ہیں۔ ساتھی کی مشین کا اپنا جدول ہے، اور اگر ٹنل کے ذیلی نیٹ کے لیے راستہ نہ ہو تو پیکٹ ڈیفالٹ گیٹ وے کی طرف جاتا ہے اور ایسی جگہ مر جاتا ہے جسے پتے کے وجود کا کوئی اندازہ نہیں۔ یہ کال کرنے والے کی طرف روٹنگ کا سوال ہے، آپ کی طرف کی اجازت نہیں۔
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
دو کلائنٹس کے درمیان سرور بھی اتنا ہی اہم ہے۔ عام ریموٹ رسائی کے ڈیزائن میں ہر کلائنٹ گیٹ وے کی طرف باہر جانے والا کنکشن کھولتا ہے اور گیٹ وے اُن بہاؤ کی حالت رکھتا ہے، اس لیے جواب اُس راستے سے واپس آتے ہیں جسے وہ پہلے سے جانتا ہے۔ ایک کلائنٹ سے دوسرے تک کنکشن نیا بہاؤ ہے جسے گیٹ وے کو قبول کر کے آگے بھیجنا ہوتا ہے، اور بہت سی تعیناتیاں کلائنٹس کو ایک دوسرے سے الگ رکھنے کے لیے اسے جان بوجھ کر بند رکھتی ہیں۔ صارفین کی VPN سروسز عام طور پر ڈیفالٹ میں الگ رکھتی ہیں؛ کارپوریٹ گیٹ وے کبھی کبھار گروپ کے مطابق اجازت دیتے ہیں۔
میزبان پر کچھ بھی بدلنے سے پہلے سمت جانچیں۔ اگر ٹنل کا پتہ خود گیٹ وے سے جواب دیتا ہے مگر کسی ساتھی سے نہیں، تو فرق گیٹ وے کی کلائنٹ-سے-کلائنٹ ترتیب ہے، اور مقامی فائر وال کی کوئی ترمیم اُس کی جگہ نہیں لے سکتی۔
آخر میں، وہ پالیسی تلاش کریں جو بہاؤ کی اجازت دیتی ہے
روٹ کیے گئے پیکٹ اور جواب دینے والی سروس کے درمیان پالیسی کی تین تہیں ہیں: VPN سرور کا بھیجنے کا فیصلہ، میزبان کی فائر وال، اور انسٹانس کے سامنے کوئی بھی کلاؤڈ سیکیورٹی گروپ۔ تینوں کو متفق ہونا چاہیے، اور وہ مختلف طریقوں سے ناکام ہوتے ہیں، اسی لیے اوپر دیے گئے جدول کی علامت براؤزر کے غلطی پیغام سے زیادہ کارآمد ہے۔
میزبان کی فائر وال وہ تہہ ہے جسے لوگ کامیاب بائنڈنگ کے بعد بھول جاتے ہیں، کیونکہ LAN انٹرفیس پر پورٹ کی اجازت دینے والا قاعدہ ٹنل کے انٹرفیس پر خود بخود اجازت نہیں دیتا۔ انٹرفیس تک محدود قواعد درست ڈیزائن ہیں اور اسی طرح اُس سروس کی عام وجہ بھی ہیں جو دفتر سے چلتی ہے مگر گھر سے نہیں۔ قاعدے کا پورٹ نمبر نہیں، اُس کا دائرہ پڑھیں۔
حالت پر مبنی فلٹرنگ اُلٹی صورت کی وضاحت کرتی ہے۔ آپ کے لیپ ٹاپ سے باہر جانے والا کنکشن حالت بناتا ہے، اور اُس کے جوابات اندر آنے والے قاعدے کے بغیر قبول ہوتے ہیں۔ ساتھی کا کنکشن بالکل نیا بہاؤ ہے جس کے پیچھے کوئی حالت نہیں، اس لیے اُسے واضح اجازت درکار ہے۔ یہی عدم توازن پوری وجہ ہے کہ آپ کی اپنی مشین پر چلنے والا براؤزر سیشن اس بارے میں کچھ نہیں کہتا کہ سروس باہر سے قابل رسائی ہے یا نہیں۔
جب ایک جانچ ناکام ہو تو ٹنل نہیں، ڈیزائن بدلیں
اگر تقاضا یہ ہے کہ ساتھی آپ کی مقامی سروس کھولے، تو ایماندار جواب عام طور پر اندرونی رسائی کے لیے بنایا گیا طریقہ کار ہوتا ہے۔ اُلٹا SSH ٹنل سب سے چھوٹا ہے: آپ کی مشین باہر کی طرف ایسے میزبان سے جڑتی ہے جہاں ساتھی پہلے ہی پہنچ سکتا ہے، اور سننے والا اُسی میزبان پر موجود ہوتا ہے۔
ssh -N -R 8443:127.0.0.1:8443 [email protected]ریلے کو اپنی SSH سرور ترتیب میں GatewayPorts clientspecified درکار ہے، ورنہ آگے بھیجا گیا سننے والا ریلے پر loopback سے بندھ جاتا ہے اور ساتھی کو پہلے جیسی ہی نفی ملتی ہے۔ دوپہر سے زیادہ دیر چلنے والی ہر چیز کے لیے صحت کی جانچ اور شائع شدہ نام کے لیے سرٹیفکیٹ والا لوڈ بیلنسر یا ingress بہتر ذریعہ ہے، اور جب دو نیٹ ورکس کو واقعی بات کرنی ہو تو دونوں ذیلی نیٹ کے لیے راستوں والا سائٹ سے سائٹ ٹنل درست جواب ہے۔
ان میں سے ہر ڈیزائن افشا کو واضح کرتا ہے، اور یہی اصل بات ہے۔ VPN پیکٹوں کو اُن نیٹ ورکس کے درمیان منتقل کرتا ہے جن کے استعمال کی آپ کو پہلے سے اجازت تھی؛ یہ کوئی سروس شائع نہیں کرتا اور لیپ ٹاپ کو انٹرنیٹ کی طرف رُخ کیے میزبان میں تبدیل نہیں کرتا۔ تین تہوں میں سے کون سی بدلنی ہے یہ طے کرنا کام ہے، اور ٹنل اُن میں سے شاذ و نادر ہی کوئی ایک ہوتا ہے۔