কন্টেইনারে vpnc রুট-ফ্লাশ সতর্কতা কেন আসে

নতুন কন্টেইনারের লগ প্রায়ই /proc/sys/net/ipv4/route/flush সম্পর্কে Read-only file system অভিযোগে শেষ হয়, আর সেই লাইনটিকে এমন একটি টানেলের দায় দেওয়া হয় যা পুরোপুরি সুস্থ হতে পারে। এর পেছনের লেখাটি কার্নেলের এমন একটি এন্ট্রিকে লক্ষ্য করে যা IPv4 রুট ক্যাশে চলে যাওয়ায় আর কোনো কাজে আসে না। কন্টেইনারের ভেতরে /proc/sys শুধু-পড়া হিসেবে মাউন্ট করা থাকে, তাই কোনো মান পৌঁছানোর আগেই রিডাইরেকশন প্রত্যাখ্যাত হয় এবং শেল সেই প্রত্যাখ্যান ছাপে। কাজ করা টানেল পুরোনো লাইনটি স্ক্রিপ্টে থাকা পর্যন্ত এই সতর্কতা ছাপতে পারে, আর --privileged লেখাটিকে কখনোই অর্থপূর্ণ করে না।

স্ক্রিপ্টটি কী ফ্লাশ করার চেষ্টা করছিল

পুরোনো সংযোগ স্ক্রিপ্টগুলো ক্যাশে পরিষ্কারের মধ্য দিয়ে শেষ হতো: কার্নেলের একটি নিয়ন্ত্রণ ফাইলে মান লেখা এবং IPv4 স্ট্যাককে তার রাউটিং ক্যাশে ফেলে দিতে বলা, যাতে পুরোনো এন্ট্রি মেয়াদ শেষ হওয়ার অপেক্ষা না করেই নতুন টানেল রুট বেছে নেওয়া যায়। ফাইলটি /proc/sys/net/ipv4/-এর অধীনে ঠিকানা করা ছিল, যা ক্রিয়াটিকে রাউটিং কমান্ড নয় বরং শেল রিডাইরেকশন বানিয়েছিল। কার্নেল 3.6 সেই ক্যাশে সরিয়ে দেয়, আর তার সঙ্গে ফ্লাশের অস্তিত্বের কারণও। বর্তমান ডেটা পথে কিছুই সেই লেখার উপর নির্ভর করে না।

এন্ট্রিটি নিজে একটি পুরোনো শুধু-লেখার ফাইল হিসেবে টিকে গেছে, তাই যে স্ক্রিপ্ট এখনো সেখানে লেখে সে একটি বাস্তব পথ ও বাস্তব অনুমতি-পরীক্ষায় পৌঁছায়। হোস্টে লেখাটি সফলতা ফেরায় এবং কিছুই বদলায় না। কন্টেইনারে একই রিডাইরেকশন শুধু-পড়া /proc/sys-এ গিয়ে EROFS দিয়ে ব্যর্থ হয়, যা শেল শুধু-পড়া ফাইলসিস্টেম বার্তা হিসেবে ছাপে। যেসব কার্নেলে পথটি সত্যিই অনুপস্থিত, সেখানে বাক্যটি No such file or directory হয়ে যায়, আর সিদ্ধান্ত বদলায় না।

দুটি ত্রুটি ভিন্ন কথা বলে, আর পার্থক্যটি স্পষ্ট রাখা দরকার। Read-only file system মানে কার্নেল একটি এন্ট্রিতে পৌঁছে লেখা প্রত্যাখ্যান করেছে; No such file or directory মানে এন্ট্রিটি আর নেই। কোনো বার্তাই টানেল ডিভাইস, রুট বা নাম-রিজলিউশন সম্পর্কে রিপোর্ট করে না, তাই কোনোটাই বেশি বিশেষাধিকার জায়েজ করে না।

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

বিশেষাধিকার যোগ করার আগে মাউন্ট ও রুট দেখুন

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

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

grep-এর উত্তর যতটা দেখায় তার চেয়ে দুর্বল, কারণ একটি মিল প্রমাণ করে লাইনটি আছে, এটি নয় যে সেটি পাহারা ছাড়া চলে; রক্ষণাবেক্ষণ করা স্ক্রিপ্ট লেখাটি এমন গার্ডের ভেতরে রাখতে পারে যা সেটি এড়িয়ে যায়। findmnt -no OPTIONS /proc/sys মাউন্ট সরাসরি নিষ্পত্তি করে, আর সেই আউটপুটে ro মানে ওই বিন্দুর নিচের প্রতিটি লেখা প্রত্যাখ্যাত, স্ক্রিপ্ট যা-ই করুক। এরপর রুট লুকআপ দেখায় অ্যাপ্লিকেশনের প্রয়োজনীয় গন্তব্যটি টানেল ইন্টারফেস দিয়ে নাকি কন্টেইনারের ডিফল্ট গেটওয়ে দিয়ে রিজলভ হয়। যে লুকআপ ডিফল্ট গেটওয়ে বেছে নেয় তার মানে টানেল উঠেছে আর সেখানে কিছুই রাউট হয় না, যা রাউটিং সমস্যা, বিশেষাধিকারের সমস্যা নয়।

সমাধানটি আসলে কোথা থেকে আসে

রক্ষণাবেক্ষণ করা সমাধান কন্টেইনার ফ্ল্যাগে নয়, স্ক্রিপ্টে থাকে। upstream vpnc-script এই ক্রিয়াটি কীভাবে সামলায় তা বদলেছে, তাই ইমেজের ভেতরের কপিটি বর্তমান upstream-এর সঙ্গে মিলিয়ে দেখুন এবং যে প্যাকেজ বা ইমেজ বিল্ড এটি সরবরাহ করে তার মাধ্যমে হালনাগাদ করুন। চলমান কন্টেইনারের ভেতরে হাতে সম্পাদিত ফাইল পর্যালোচনাযোগ্য নয় এবং পরের বিল্ড পর্যন্ত টিকবে না।

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