OpenVPN কি পুরোনো রুট পাঠিয়েই চলেছে? সে আসলে কী লোড করেছে দেখুন

আপনি একটি রুট পুশ যোগ করেন, সার্ভিস রিস্টার্ট করেন, আবার সংযোগ করেন, আর ক্লায়েন্টের টেবিল আগের মতোই দেখায়। দুটি ভিন্ন বিষয় সত্য হতে পারে: সার্ভার আপনার সম্পাদনা লোড করেনি, অথবা ক্লায়েন্ট যা পেয়েছে তা ইনস্টল করেনি। উপসর্গ ছাড়া দুটির মধ্যে কোনো মিল নেই, তাই প্রথম কাজটি হলো আপনার কোনটি ঘটেছে তা বের করা।

নিচের তুলনাটি প্রসেস থেকে বাইরের দিকে এগোয়, কারণ কোন ফাইল কার্যকর তা একমাত্র প্রসেসই জানে।

আপনি যে ফাইল সম্পাদনা করেছেন আর প্রসেস যে ফাইল পড়ছে

শুরু করুন unit আর তার তৈরি কমান্ড লাইন দিয়ে। systemd হোস্টে systemctl cat openvpn@server ExecStart লাইনটি ছাপে, আর একটি instance unit সাধারণত instance-এর নাম থেকে তার কনফিগারেশন পাথ নেয়, তাই openvpn@office নামে চালু ডেমন openvpn@server নামে চালু ডেমন থেকে ভিন্ন ফাইল পড়ে। এটিকে চলমান প্রসেসের argv-এর সঙ্গে মিলান। কনফিগারেশন ম্যানেজমেন্ট টুল পরিবর্তন হারানোর আরেকটি পথ যোগ করে: এটি সঠিক ফাইল এমন জায়গায় লিখতে পারে যা unit কখনো উল্লেখ করে না, ফলে সফল ডিপ্লয় নিষ্ক্রিয় দেখায়।

টাইমস্ট্যাম্প দ্রুত বিষয়টি ঠিক করে দেয়: ফাইলটি প্রসেস শুরুর সময়ের চেয়ে নতুন হলে প্রসেস তা পড়তে পারেনি। রাউটার ফার্মওয়্যার তৃতীয় একটি ক্ষেত্র যোগ করে, কারণ অনেক মডেল তাদের সেটিংস flash-এ রাখে এবং বুটের সময় কনফিগারেশন নতুন করে তৈরি করে, ফলে ডিস্কে ফাইল সম্পাদনা সম্পূর্ণ ভুল স্তরে পড়ে।

সার্ভার কী পুশ করে আর ক্লায়েন্ট কী ইনস্টল করে

একটি পুশ করা রুটকে দুটি ফিল্টার পার হতে হয়। সার্ভারে এটি অবশ্যই লোড করা কনফিগারেশনে থাকতে হবে, কোনো কমেন্ট করা ব্লকে বা এমন ক্লায়েন্ট-নির্দিষ্ট ফাইলে নয় যার নাম মিলছে না। ক্লায়েন্টে pull চালু থাকতে হবে এবং কোনো pull-filter সেই অপশনটি ফেলে দিতে পারবে না। verbosity 4 দিয়ে সংযোগ করুন এবং ক্লায়েন্ট যে পুশ করা অপশন জানায় তা পড়ুন: রুটটি সেই তালিকায় থাকলে সার্ভার তার কাজ করেছে, আর ক্লায়েন্টই এটি ইনস্টল না করার সিদ্ধান্ত নিচ্ছে।

ক্লায়েন্ট-নির্দিষ্ট ফাইল প্রায়ই বিভ্রান্তির উৎস। সার্টিফিকেটের common name অনুযায়ী নাম দেওয়া ফাইল কেবল সেই ক্লায়েন্টকেই অপশন পুশ করে, আর এক অক্ষরের অমিল পুশটি নিঃশব্দে থামিয়ে দেয়, কোনো পক্ষেই কোনো ত্রুটি দেখায় না। সার্ভার সংযোগের সময় যে common name দেখেছে তা লগ করে, তাই সেই মানটি ফাইলের নামের সঙ্গে মিলান, আপনি ক্লায়েন্টের নাম কী ভাবছেন তার সঙ্গে নয়।

পুশ করা প্রিফিক্স আর ফেরতের রুট ভিন্ন সমস্যা

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

ক্লায়েন্টে সেই রুট যোগ করলে সার্ভার-উদ্যাপিত প্রোবের উত্তর ঠিক হয়। এটি পুশ করা সাবনেট রুটের বিকল্প নয়, আর উল্টোটাও সত্য, কারণ দুটি ভিন্ন দিকের যাত্রা বোঝায়।

দুই প্রান্তের টেবিল মিলিয়ে দেখুন

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

তিনটি শনাক্তকারী একসঙ্গে রাখুন: কনফিগারেশন পাথ, unit বা instance-এর নাম, এবং যে ক্লায়েন্ট পরিচয় দিয়ে আপনি পরীক্ষা করেছেন।

এই তিনটি পরের ঘটনাটিকে পুনরায় তদন্তের বদলে পাঁচ মিনিটের যাচাইয়ে পরিণত করে, আর টানেল যখন অন্য কারো সমস্যা হয়ে যায় তখন সহকর্মীর যা দরকারও এগুলিই।

রিস্টার্টের পরেও টিকে থাকা রুট সমস্যা প্রায়ই আদৌ রাউটিং সমস্যা নয়; ত্রুটি আপনি বারবার যে টেবিল পড়ছেন তার উপরের স্তরে থাকে।