VPN কন্টেইনারে DNAT: INPUT নয়, ফরওয়ার্ডিং

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

অনুবাদের পরে প্যাকেট অনুসরণ করুন

10.90.0.0/24 ক্লায়েন্ট পুল এবং 10.90.0.1 টানেল ঠিকানা ধরুন। একটি ব্রিজে দুটি কন্টেইনার আছে: 192.0.2.2 VPN চালায় এবং 192.0.2.3 অ্যাপ্লিকেশন চালায়। একটি ক্লায়েন্ট 10.90.0.1:8080-এ সংযোগ করে, আর VPN কন্টেইনারের নেমস্পেসের DNAT নিয়ম সেটি অ্যাপ্লিকেশনের প্রকৃত ঠিকানা ও পোর্টে পুনর্লিখন করে। তারপর একটি রুট প্যাকেটটি ব্রিজের ওপর দিয়ে পাঠায়। এই ঠিকানাগুলো উদাহরণ, কোনো ডিপ্লয়মেন্ট রেসিপি নয়।

অ্যাপ্লিকেশনটি যে পোর্টে সত্যিই শোনে তা হোস্টে প্রকাশিত যেকোনো পোর্ট থেকে আলাদা হতে পারে। দুটি সংখ্যা মিলে যাবে ধরে নেওয়ার বদলে কন্টেইনারের ভেতরের লিসেনার পড়ুন।

অনুমতি ফরওয়ার্ড পথের ওপর নির্ভর করে

VPN কন্টেইনারের IP ফরওয়ার্ডিং এবং ক্লায়েন্ট পুল, অ্যাপ্লিকেশনের ঠিকানা ও অভীষ্ট পোর্টে সীমিত একটি ফরওয়ার্ডিং সিদ্ধান্ত দরকার। প্রতিষ্ঠিত উত্তরগুলোর জন্য আলাদা অনুমতি দরকার। মূল টানেল ঠিকানার সঙ্গে মেলা নিয়ম DNAT-এর পরে মিলবে না, কারণ গন্তব্য ইতিমধ্যে বদলে গেছে। INPUT অনুমতি এমন ট্র্যাফিকের জন্য ভুল হুক, যা আর এই হোস্টের ঠিকানায় নেই।

পরিধি সংকীর্ণ রাখুন: একটি সোর্স রেঞ্জ, একটি গন্তব্য, একটি সেবা। উদার ফরওয়ার্ডিং নিয়ম লিখতে সহজ এবং পরে রক্ষা করা অনেক কঠিন।

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker-এর চেইন আপনার কন্টেইনারের চেইন নয়

কন্টেইনার নেমস্পেসের ভেতরের নিয়মগুলো Docker হোস্টের নিয়ম নয়। যখন ট্র্যাফিক টানেল ইন্টারফেস থেকে ব্রিজে যায়, হোস্টের ব্রিজ ফায়ারওয়াল আরেকটি সিদ্ধান্ত নিতে পারে। Docker-এর iptables ব্যাকএন্ডে নথিভুক্ত ফরওয়ার্ডিং চেইন ও DNAT-পরবর্তী মিলনের বিন্দুই সেই সিদ্ধান্তের জায়গা।

Docker ফায়ারওয়াল রেফারেন্স সেই চেইনগুলো ও DNAT-পরবর্তী মিলন বর্ণনা করে। Docker-এর ফায়ারওয়াল ব্যবস্থাপনা বন্ধ করে বা প্রতিটি চেইন উদার করে অনুপস্থিত অনুমোদন ঠিক করবেন না, কারণ এতে আপনি যে সীমা ব্যবহার করতে চাইছেন তা সরে যায়।

ফেরার পথকে সচেতন পছন্দ করুন

সোর্স ঠিকানা সংরক্ষিত থাকলে অ্যাপ্লিকেশন 10.90.0.x দেখে এবং অবশ্যই উত্তরগুলো VPN কন্টেইনার দিয়ে ফেরত পাঠাবে. নইলে তার সাধারণ Docker গেটওয়ে সেগুলো হোস্টে পাঠাবে, যে টানেলের মালিক নয়। বিকল্প হলো VPN কন্টেইনারে সংকীর্ণ সোর্স অনুবাদ, যা উত্তর সরল করে কিন্তু অ্যাপ্লিকেশন থেকে ক্লায়েন্টকে লুকায়। সচেতনভাবে বেছে নিন এবং কোনটি বেছেছেন লিখে রাখুন।

সাধারণ ক্লায়েন্ট থেকে একটি নতুন অনুমোদিত সংযোগ পরীক্ষা করুন, তারপর নিশ্চিত করুন অসম্পর্কিত পোর্ট বন্ধ আছে। প্যাকেট হারিয়ে গেলে VPN নেমস্পেস, অ্যাপ্লিকেশন নেমস্পেস ও অ্যাপ্লিকেশনের নিজের লগ দেখুন। ব্রিজ গেটওয়েতে ping সেবার জন্য গ্রহণযোগ্যতা পরীক্ষা নয়।

নিয়মগুলো কন্টেইনারের সমর্থিত স্টার্টআপ কনফিগারেশনে রাখুন, কারণ পুনরায় তৈরি হলে ইন্টারঅ্যাকটিভ সম্পাদনা হারিয়ে যায়। হোস্ট পোর্ট প্রকাশ করা ভিন্ন এক্সপোজার পথ এবং শুধু টানেল দিয়ে সেবা পৌঁছানো যায় বলে এর দরকার নেই।