VPN কন্টেইনারের নেটওয়ার্ক শেয়ার করা: DNS-এ কী ঘটে

VPN কন্টেইনারের নেটওয়ার্ক নেমস্পেস শেয়ার করলে আপনার অ্যাপ্লিকেশন টানেলের ইন্টারফেস ও রুট পায়। এটি তাকে টানেলের রিজলভার দেয় না, হোস্টে থাকা অন্য কিছুর একীভূত কপিও নয়। এই ফাঁক খুব নির্দিষ্ট একটি ত্রুটি তৈরি করে: পাবলিক নাম রিজলভ হয়, অভ্যন্তরীণ নাম হয় না, আর যে অ্যাপ ব্যর্থ হয় তা ভুল DNS সার্ভার ব্যবহার করছে বলে মনে হয়, কারণ সত্যিই তাই। মেরামত সাধারণত রোগনির্ণয় যতটা ইঙ্গিত দেয় তার চেয়ে ছোট।

ধাপ 1: হোস্ট থেকে নয়, অ্যাপ থেকে পরীক্ষা করুন

যে কন্টেইনারে সমস্যা আছে তার ভেতরে লুকআপ চালান, হোস্টে বা ব্রাউজারে নয়। docker exec app-container getent hosts db.internal একমাত্র গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়: এই প্রসেসের রিজলভার কী ফেরত দেয়।

হোস্ট যদি নাম রিজলভ করে আর কন্টেইনার না করে, তাহলে আপনি ত্রুটিটি খুঁজে পেয়েছেন। এর পরের সবকিছুই এটি ঠিক করার একটি সমর্থিত উপায় বেছে নেওয়া।

ধাপ 2: রানটাইমের সমর্থিত মডেল পড়ুন

Docker-এর নেটওয়ার্ক ডকুমেন্টেশন অন্য কন্টেইনারের নেটওয়ার্ক মোড শেয়ার করা কন্টেইনারগুলোর DNS ফ্ল্যাগে বিধিনিষেধ লিপিবদ্ধ করে। Compose-এ network_mode: service:vpn অ্যাপকে VPN কন্টেইনারের নেমস্পেসের সাথে বেঁধে দেয়, এবং প্রতি-সার্ভিস dns সেটিংস সাধারণ সার্ভিসের মতো আচরণ করে না। আপনি যে সমাধান পান সেটিই শেয়ার করা নেমস্পেসের আছে।

ব্যবহারকারী-সংজ্ঞায়িত ব্রিজ নেটওয়ার্কও ডিফল্ট ব্রিজের চেয়ে ভিন্নভাবে Docker-এর এমবেডেড DNS ব্যবহার করে। এজন্যই একটি dns স্ট্যানজা কাজ করা ব্রিজ উদাহরণ থেকে কপি করলে শেয়ার করা স্ট্যাকে কিছুই করতে পারে না। স্ট্যানজা কপি করার আগে ব্যবস্থাটি যাচাই করুন।

লুপব্যাক ঠিকানা সবসময় প্রাসঙ্গিক নেটওয়ার্ক প্রসঙ্গকেই বোঝায়। শেয়ার করা নেমস্পেসের ভেতরে 127.0.0.1 হোস্টের রিজলভার নয়।

ধাপ 3: কোয়েরিটিকে তার প্রাপক পর্যন্ত অনুসরণ করুন

অ্যাপের রিজলভার কনফিগারেশন পড়ুন, তারপর অ্যাপের সাথে আসা যেকোনো অ্যাপ-নির্দিষ্ট এনক্রিপ্টেড DNS পড়ুন, কারণ নিজের রিজলভার চালানো অ্যাপ আপনার সম্পাদিত ফাইল উপেক্ষা করে। তারপর দেখুন নির্বাচিত রিজলভারটি VPN-এর রুট ও ফায়ারওয়াল নীতির অধীনে পৌঁছানো যায় কি না। টানেলের ওপারে থাকা রিজলভার ঠিকানা অর্থহীন যদি নেমস্পেসের সেখানে কোনো রুট না থাকে। কোনো ফাইল সম্পাদনা করার আগে প্রাপক নিশ্চিত করুন।

ব্রাউজারের IP-যাচাই পৃষ্ঠা বলতে পারে না নাম কোয়েরিগুলো কোথায় গেছে। এটি বলে একটি HTTP সংযোগ কোথায় গেছে।

ধাপ 4: দুটি ব্যর্থতার শ্রেণি ভিন্নভাবে ঠিক করুন

সার্ভিসের নাম ব্যর্থ হলে অথচ পাবলিক নাম কাজ করলে, সমস্যা কন্টেইনার নেটওয়ার্কের ভেতরের সার্ভিস ডিসকভারিতে, পাবলিক রিজলভার তালিকায় নয়। প্রতিটি পাবলিক DNS ঠিকানা বদলালে এমন রেকর্ড তৈরি হবে না যা নেটওয়ার্কের ডিসকভারি ব্যবস্থার কাছে কখনো চাওয়া হয়নি।

দুটি শ্রেণিই ব্যর্থ হলে রিজলভারে পৌঁছানোর ক্ষমতা দিয়ে শুরু করুন। কেবল একটি ব্যর্থ হলে ডিসকভারি ব্যবস্থা দিয়ে শুরু করুন। দুটির মালিক আলাদা, তাই একটি মেরামত কখনো দুটিকেই ঢাকে না।

ধাপ 5: পুনরায় তৈরি করার পরে আবার পরীক্ষা করুন

রানটাইমের সমর্থিত ব্যবস্থার মাধ্যমে কনফিগারেশন বদলান, তারপর চলমান কন্টেইনারের ভেতরে ফাইল সম্পাদনা না করে কন্টেইনারগুলো পুনরায় তৈরি করুন। একটি নতুন প্রাইভেট নাম, একটি নতুন পাবলিক নাম এবং লুকআপের পরের অ্যাপ্লিকেশন অনুরোধ পরীক্ষা করুন। /etc/resolv.conf কন্টেইনারের ভেতরে সম্পাদনা পুনরায় তৈরি হলে মুছে যায় এবং আপনাকে বিশ্বাস করাবে যে মেরামত কাজ করেছে, অথচ করেনি।

শেয়ার করা নেটওয়ার্ক সংজ্ঞার পাশে রিজলভারের মালিক ও প্রত্যাশিত নেমস্পেস লিখে রাখুন। পরের ব্যক্তির দুটিই লাগবে।