آپ کا Docker VPN پورٹ میپنگ OpenVPN تک کیوں کبھی نہیں پہنچتا
میزبان پورٹ، کنٹینر پورٹ اور ٹرانسپورٹ تین الگ فیصلے ہیں۔ سرٹیفکیٹ چھونے سے پہلے ایک UDP کوشش کو ہر حد سے گزاریں۔
آپ کا کنٹینر UDP 1195 پر سن سکتا ہے جبکہ میزبان 1194 شائع کرتا ہے، اور یہ درست ہے جب تک میپنگ ایسا کہتی ہے۔ نمبر ایک ترجمہ جدول بناتے ہیں: کلائنٹ میزبان پورٹ ڈائل کرتا ہے، Docker منزل کو کنٹینر پورٹ پر دوبارہ لکھتا ہے، اور OpenVPN اُس پورٹ پر جواب دیتا ہے جس کا نام اُس کی اپنی ترتیب بتاتی ہے۔ اِن میں سے کسی بھی کڑی میں عدم مطابقت فائر وال جیسی دکھنے والی خاموش ناکامی پیدا کرتی ہے۔ سرٹیفکیٹ اور سائفر اِس کے بعد ہیں اور اِسے ٹھیک نہیں کر سکتے۔
تصدیق کے بارے میں کچھ بھی بدلنے سے پہلے ایک پیکٹ کو کلائنٹ سے عمل تک ٹریک کریں۔
تین نمبر، ایک کنکشن
یہ تین نمبر وہ دور منزل ہیں جو کلائنٹ استعمال کرتا ہے، میزبان پر شائع شدہ میپنگ، اور کنٹینر کے اندر سننے والا۔ اِن کا برابر ہونا ضروری نہیں، مگر اِنہیں زنجیر بننا چاہیے۔ برابر نمبر ایک خاص صورت ہے جو اتفاقاً سب سے عام ہے، اِس لیے عدم مطابقت ایک بار لکھنا آسان اور بعد میں دیکھنا مشکل ہوتا ہے۔
ڈیبگ کرنے سے پہلے زنجیر کو ایک سطر میں لکھیں: کلائنٹ کا پتہ اور پورٹ، میزبان میپنگ، کنٹینر سننے والا، ٹرانسپورٹ۔ زنجیر میں نقص اُس نمبر کی صورت میں ظاہر ہوتا ہے جو مختلف اقدار کے ساتھ دو بار آتا ہے۔
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
مختصر نحو اصل میں کیا کہتی ہے
مختصر شکل میں بائیں طرف میزبان پورٹ اور دائیں طرف کنٹینر پورٹ ہے، اور سلیش لاحقہ ٹرانسپورٹ منتخب کرتا ہے۔ لاحقہ چھوڑ دیں تو Docker میپنگ کو TCP سمجھتا ہے، اِس لیے پروٹوکول کے بغیر میپنگ کے پیچھے UDP سننے والا ایسا سننے والا ہے جہاں کوئی نہیں پہنچ سکتا۔ یہ طے شدہ رویہ دستاویزی ہے اور اب بھی اُن لوگوں کو حیران کرتا ہے جنہوں نے نمبر ملائے اور کام ختم سمجھ لیا۔
طویل شکل بائنڈ پتہ اور پروٹوکول واضح طور پر مقرر کرتی ہے، جو نیٹ ورک کی طرف کسی بھی چیز کے لیے اضافی سطروں کے لائق ہے۔ اُس فائل پر بھروسا کرنے کے بجائے جو میپنگ بناتی ہے، شائع شدہ میپنگ دوبارہ پڑھیں۔
ports:
- 1194:1195/udpپیکٹ کہاں رک سکتا ہے
درخواست Docker سے پہلے، Docker میں یا سننے والے پر گرا دی جا سکتی ہے۔ Docker سے آگے کلاؤڈ فائر وال یا خود فارورڈ کرنے والا راؤٹر ہو سکتا ہے، اور اُس ڈیوائس کو میزبان کی طرف والا پورٹ اور درست ٹرانسپورٹ چاہیے۔ Docker کے اندر غلط کنٹینر پورٹ کی میپنگ بند ساکٹ کی طرف بھیجتی ہے۔
پھر سننے والا: OpenVPN کی ترتیب ایک پورٹ اور پروٹوکول بتاتی ہے، اور کنٹینر کے اندر کسی دوسرے پر آنے والا کلائنٹ کہیں نہیں پہنچتا۔ UDP سروس کا TCP سے امتحان اِن میں سے کسی مرحلے پر کچھ ثابت نہیں کرتا، اِس لیے وہی ٹرانسپورٹ استعمال کریں جو کلائنٹ استعمال کرے گا۔
بائنڈ پتے رسائی کا تعین کرتے ہیں
loopback سے بندھی شائع شدہ میپنگ صرف میزبان سے قابلِ رسائی ہوتی ہے، جبکہ تمام انٹرفیس سے بندھی وہ جگہ قابلِ رسائی ہوتی ہے جہاں فائر وال اجازت دے۔ پتہ چھوڑنے والی Compose فائل میں دونوں ایک جیسی دکھتی ہیں، اور Docker کا طے شدہ رویہ چوڑا ہے۔
طے کریں کہ تعیناتی کون سی نمائش چاہتی ہے، پھر اُسے واضح لکھیں۔ loopback سے جڑنے والا اندرونی امتحان اور جڑ نہ سکنے والا دور دراز کلائنٹ دونوں ایک ہی کنٹینر کی درست تفصیل ہو سکتے ہیں۔
چلتی حالت پڑھیں
چلتے کنٹینر کی حقیقی میپنگ اور اُس کے نیٹ ورک نام کی جگہ میں سننے والے کا معائنہ کریں۔ کنٹینر شروع ہونے کے بعد Compose فائل میں ترمیم ہو سکتی ہے، امیج میٹا ڈیٹا پورٹ شائع کیے بغیر اعلان کر سکتا ہے، اور دوسرا کنٹینر پہلے ہی میزبان پورٹ رکھ سکتا ہے۔ امیج میں پورٹ کا اعلان کرنا اُسے شائع کرنا نہیں، اور دونوں میں سے کوئی بھی سننے کے برابر نہیں۔
تین مختلف حالتیں، تین مختلف کمانڈیں، اور صرف آخری OpenVPN سے متعلق ہے۔
میپنگ درست ہونے کے بعد
پیکٹ OpenVPN تک پہنچنے کے بعد اُس کا لاگ TLS اور تصدیق کے بارے میں پڑھنے کی جگہ ہے۔ کبھی نہ آنے والے پیکٹ کو ٹھیک کرنے کے لیے سرٹیفکیٹ دوبارہ بنانا دوسرا متغیر شامل کرنے والا بیکار کام ہے۔ میپنگ کا نوٹ کلائنٹ پروفائل کے پاس رکھیں تاکہ اگلا شخص تینوں نمبر دوبارہ دریافت کرنے کے بجائے ایک سطر پڑھے۔ میزبان کی طرف ایک بار پیکٹ کیپچر کرنا طے کرتا ہے کہ تین کڑیوں میں کون سی غلط ہے، اور اِس کی لاگت سرٹیفکیٹ دوبارہ بنانے سے کم ہے۔
یہاں بیان کردہ معاملہ پل کے ذریعے اشاعت کا ہے۔ میزبان نیٹ ورکنگ اور روٹ شدہ کنٹینر پتے ترجمہ چھوڑ دیتے ہیں، اِس لیے اُن ڈیزائنوں میں وہی نمبر کچھ اور معنی رکھتے ہیں۔