কেন আপনার 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 পরীক্ষা এই কোনো পর্যায়ে কিছুই প্রমাণ করে না, তাই ক্লায়েন্ট যে ট্রান্সপোর্ট ব্যবহার করবে সেটিই ব্যবহার করুন।
বাইন্ড ঠিকানা নাগাল নির্ধারণ করে
লুপব্যাকে বাঁধা প্রকাশিত ম্যাপিং কেবল হোস্ট থেকেই নাগালের মধ্যে, আর সব ইন্টারফেসে বাঁধা ম্যাপিং ফায়ারওয়াল যতদূর অনুমতি দেয় ততদূর নাগালের মধ্যে। ঠিকানা বাদ দেওয়া Compose ফাইলে দুটো একই রকম দেখায়, আর Docker-এর ডিফল্ট হলো প্রশস্তটি।
স্থাপনাটি কোন প্রকাশ চায় তা ঠিক করুন, তারপর স্পষ্টভাবে লিখুন। লুপব্যাক দিয়ে সংযোগ করা অভ্যন্তরীণ পরীক্ষা আর সংযোগ করতে না পারা দূরবর্তী ক্লায়েন্ট—দুটোই একই কন্টেইনারের নির্ভুল বর্ণনা হতে পারে।
চলমান অবস্থা পড়ুন
চলমান কন্টেইনারের কার্যকর ম্যাপিং ও তার নেটওয়ার্ক নেমস্পেসের শ্রবণকারী পরীক্ষা করুন। কন্টেইনার চালু হওয়ার পরে Compose ফাইল সম্পাদিত হয়ে থাকতে পারে, ইমেজ মেটাডেটা পোর্ট প্রকাশ না করেই ঘোষণা করতে পারে, আর দ্বিতীয় কন্টেইনার ইতিমধ্যে হোস্ট পোর্ট ধরে রাখতে পারে। ইমেজে পোর্ট ঘোষণা করা মানে তা প্রকাশ করা নয়, আর কোনোটিই শোনার সমান নয়।
তিনটি ভিন্ন অবস্থা, তিনটি ভিন্ন কমান্ড, এবং কেবল শেষটিতেই OpenVPN জড়িত।
ম্যাপিং সঠিক হওয়ার পরে
প্যাকেট OpenVPN-এ পৌঁছালে তার লগই TLS ও প্রমাণীকরণ সম্পর্কে পড়ার জায়গা। কখনো না আসা প্যাকেট ঠিক করতে সার্টিফিকেট পুনরায় তৈরি করা অপচয়, যা দ্বিতীয় চলক যোগ করে। ম্যাপিংয়ের নোটটি ক্লায়েন্ট প্রোফাইলের পাশে রাখুন যাতে পরের ব্যক্তি তিনটি সংখ্যা নতুন করে আবিষ্কার না করে এক লাইন পড়েন। হোস্টের দিকে একবার প্যাকেট ক্যাপচার করলেই তিনটি শৃঙ্খলের কোনটি ভুল তা ঠিক হয়ে যায়, আর এর খরচ সার্টিফিকেট পুনরায় তৈরির চেয়ে কম।
এখানে বর্ণিত ঘটনাটি হলো ব্রিজ প্রকাশ। হোস্ট নেটওয়ার্কিং ও রুটেড কন্টেইনার ঠিকানা অনুবাদটি এড়িয়ে যায়, তাই সেই নকশাগুলোতে একই সংখ্যা ভিন্ন কিছু বোঝায়।