কেন macvlan কন্টেইনার VPN ক্লায়েন্টকে উত্তর দিতে পারে না

এমন একটি Linux হোস্ট কল্পনা করুন যা একটি VPN টার্মিনেট করে এবং একই সঙ্গে macvlan নেটওয়ার্কে একটি কন্টেইনার চালায়। LAN হল 192.168.60.0/24, কন্টেইনারটি 192.168.60.210 ধরে আছে, আর VPN ক্লায়েন্টরা আসে 10.95.0.0/24 থেকে। ক্লায়েন্ট সেবায় পৌঁছায়, উত্তর কখনও ফিরে আসে না, আর হোস্টের প্রতিটি ফায়ারওয়াল নিয়ম ঠিক দেখায়। দুটি আলাদা সীমাবদ্ধতা এই উপসর্গ তৈরি করে, আর একটির সমাধান করলে অন্যটি জায়গাতেই থাকে।

দুটি সীমাবদ্ধতা, একটি উপসর্গ

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

দ্বিতীয় সীমাবদ্ধতা হল ফিরতি পথ। কন্টেইনারের ডিফল্ট গেটওয়ে সাধারণত LAN রাউটার, তাই VPN ক্লায়েন্টের উদ্দেশ্যে পাঠানো উত্তর ওই রাউটার দিয়েই বেরোয়। রাউটারের যদি VPN পুলে ফেরার কোনো রুট না থাকে, উত্তর মাঝপথে কোথাও ফেলে দেওয়া হয়।

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

হোস্টের দিকের শিম সংকীর্ণভাবে তৈরি করুন

হোস্টে একই প্যারেন্টের সঙ্গে ব্রিজ মোডে যুক্ত দ্বিতীয় একটি macvlan ইন্টারফেস হোস্ট স্ট্যাককে ওই LAN সেগমেন্টে নিজস্ব পরিচয় দেয়। এর জন্য DHCP পুলের বাইরে এবং কন্টেইনার পরিসরের বাইরে একটি ঠিকানা সংরক্ষিত রাখুন, আর শুধু কন্টেইনারটিকে এর মধ্য দিয়ে রুট করুন।

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

প্রথম কমান্ডটি ইন্টারফেস তৈরি করে ব্রিজ মোডে, যা এই ড্রাইভারের নথিভুক্ত ডিফল্ট এবং হোস্ট-কন্টেইনার ট্রাফিকের জন্য আপনি যে মোড চান সেটিই। দ্বিতীয়টি /32 বরাদ্দ করে যাতে ঠিকানাটি LAN প্রিফিক্সের সঙ্গে সংঘর্ষ না করে, আর চতুর্থটি শিমের মধ্য দিয়ে শুধু কন্টেইনারের ঠিকানা পাঠায়।

নতুন ইন্টারফেস দিয়ে পুরো LAN পুনর্নির্দেশ করবেন না। সাধারণ সংযুক্ত রুট যেমন আছে তেমনই থাকে, আর হোস্ট রুট ইচ্ছাকৃতভাবে সংকীর্ণ যাতে একটি কন্টেইনার পথ পায় কিন্তু সেগমেন্টের বাকি অংশের আচরণ না বদলায়। শিমের দিকে নির্দেশ করা একটি ডিফল্ট রুট ভিন্ন পরিণতিসহ ভিন্ন একটি নকশা হবে। এটিকে নির্দিষ্ট রাখুন, ক্ষতির পরিসর ছোটই থাকবে।

এই কমান্ডগুলি চলমান হোস্টে নেটওয়ার্কিং বদলায়। অ্যাপ্লায়েন্স বা ম্যানেজড প্ল্যাটফর্মে সেই প্ল্যাটফর্মের সমর্থিত কনফিগারেশন ব্যবস্থা ব্যবহার করুন, কারণ ইন্টারঅ্যাকটিভ root-shell পরিবর্তন আপগ্রেডের পর টিকে না-ও থাকতে পারে।

সোর্স কীভাবে সংরক্ষিত হবে তা ঠিক করুন

শিম থাকলে কন্টেইনার হোস্টে পৌঁছাতে পারে, আর প্রশ্ন হয় উত্তরটি কোন সোর্স ঠিকানা বহন করে। মূল VPN সোর্স সংরক্ষণ করা বেশি পরিচ্ছন্ন মডেল: কন্টেইনার আসল ক্লায়েন্ট ঠিকানা দেখে, আর সেবার লগ ও অ্যাক্সেস নিয়ম তা ব্যবহার করতে পারে।

সেটি কাজ করতে হলে কন্টেইনারের নেটওয়ার্ক কনফিগারেশনকে এই পথের জন্য 10.95.0.0/24-এর ট্রাফিক 192.168.60.250-এ তার গেটওয়ে হিসেবে পাঠাতে হবে। এটি কন্টেইনারের নিজের কনফিগারেশনের ভিতরে সমর্থিত রুট বা গেটওয়ে সেটিং, হোস্টের দিকের কোনো কৌশল নয়। সেটিং কার্যকর হয়েছে ধরে নেওয়ার বদলে কন্টেইনারের ভিতর থেকে নিশ্চিত করুন। যে ডিফল্ট গেটওয়ে এখনও LAN রাউটারের দিকে দেখায়, সে উত্তর একই গর্তে পাঠাতে থাকবে।

অনুমোদিত নকশা যদি বরং VPN সোর্সগুলি লুকায়, তবে অনুবাদটি সংকীর্ণভাবে সীমাবদ্ধ করুন: আসল VPN পুল, আউটগোয়িং ইন্টারফেস হিসেবে শিম, আর নির্দিষ্ট কন্টেইনার ও সেবা।

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

শিমকে ইগ্রেস ইন্টারফেস হিসেবে মিলান, টানেল নয়। যে নিয়ম টানেলকে আউটগোয়িং ইন্টারফেস বলে, তা কন্টেইনারের দিকে যাওয়া প্যাকেটের সঙ্গে মিলবে না, আর এই ধরনের সেটআপে সাধারণত এই ভুলটিই থাকে। নিয়মটি উপরের বাক্যের মতোই সংকীর্ণ রাখুন এবং পুল বদলালে তা পর্যালোচনা করুন।

ক্লায়েন্ট থেকে যাচাই করুন, হোস্ট থেকে নয়

হোস্ট নিজে থেকে শিমের ঠিকানায় বাঁধা একটি অনুরোধ প্রমাণ করে যে শিম কন্টেইনারে পৌঁছাতে পারে। এটি প্রমাণ করে না যে কন্টেইনার সংরক্ষিত 10.95.0.x সোর্সে ট্রাফিক ফেরত দিতে পারে, কারণ সেই পরীক্ষায় সোর্স ঠিকানা শিমের নিজের।

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

প্রথম কমান্ড হোস্ট-থেকে-কন্টেইনার অংশটি পরীক্ষা করে, আর দ্বিতীয়টি দেখায় আসলে কী শিমের মধ্য দিয়ে যায় যখন একটি আসল VPN ক্লায়েন্ট অনুরোধ করে। ভিতরে আসার পথে সোর্স ঠিকানা দেখুন এবং একই প্রবাহে উত্তর আসে কি না দেখুন।

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

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