OpenVPN-এ রুটে "File exists" কোনো ফাইল সমস্যা নয়

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

ক্লায়েন্টের নিজস্ব ক্রম অনুসরণ করুন: সে কী চেয়েছিল, টেবিলে আগে থেকেই কী ছিল, সেই এন্ট্রিটি সেখানে কে রেখেছিল, এবং তারপরেই কী বদলাতে হবে। প্রতিটি ধাপ একটি সম্ভাব্য মালিককে বাদ দেয়।

ক্লায়েন্ট আসলে কী চাইছিল

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

রুট হেল্পারের অশূন্য এক্সিট স্ট্যাটাস তার নিচের লেখার চেয়ে কম তথ্যবহ, কারণ বিভিন্ন কার্নেল প্রতিক্রিয়া অশূন্য স্ট্যাটাস দেয়। সঠিক বার্তাটি ধরে রাখুন; বিদ্যমান এন্ট্রি আর অপ্রাপ্য গেটওয়ের মধ্যে পার্থক্যই ঠিক করে পরের কোন অংশগুলো প্রযোজ্য।

বিদ্যমান রুটটি পড়ুন, শুধু ঠিকানাটি নয়

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

একটি প্রিফিক্সের চারটি মালিক থাকতে পারে

সংযুক্ত রুট আসে বরাদ্দ করা ঠিকানা থেকে এবং ওই ঠিকানা থাকলেই সিস্টেম সেগুলো পুনরায় তৈরি করে। DHCP ক্লায়েন্ট বা কানেকশন ম্যানেজার নিজের জীবনচক্রের অংশ হিসেবে রুট ইনস্টল করে। আরেক VPN ক্লায়েন্ট ইতিমধ্যেই একই প্রিফিক্স বহন করতে পারে। আর একটি স্থানীয় হুক বা স্ক্রিপ্ট এমন একটি যোগ করতে পারে যা অন্য কিছু জানে না।

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

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

block-local ভিন্ন প্রশ্নের উত্তর দেয়

একটি প্রোফাইল সব ট্র্যাফিক টানেল দিয়ে পাঠালে স্থানীয় নেটওয়ার্কের কী হবে তা ক্লায়েন্টকে ঠিক করতে হয়। block-local ফ্ল্যাগ স্থানীয় LAN-কে টানেল দিয়ে রুট করে সেই সিদ্ধান্ত বদলায়, একই সঙ্গে LAN গেটওয়ের জন্য নথিভুক্ত ব্যতিক্রম রাখে; এটি ট্র্যাফিক নীতির সিদ্ধান্ত যার প্রাপ্যতার উপর দৃশ্যমান প্রভাব আছে।

এটি ব্যাখ্যা করে না কেন রুট অ্যাড বিদ্যমান-এন্ট্রি ত্রুটি ফেরত দিল, আর এটিকে সর্বজনীন সমাধান হিসেবে গ্রহণ করলে প্রকৃত সংঘর্ষ নীতির পরিবর্তনের আড়ালে ঢাকা পড়ে। প্রোফাইল সম্পাদনার পরে আপনার স্থানীয় সম্পদ নাগালের বাইরে গেলে এই ফ্ল্যাগ প্রথমে দেখার মতো জিনিসগুলোর একটি; রুট অ্যাড ব্যর্থ হলে এটি উত্তর নয়।

এটিকে কোন গন্তব্যগুলো স্থানীয় থাকবে সেই সিদ্ধান্ত হিসেবে দেখুন, যা সচেতনভাবে নেওয়া ও লিখে রাখা হয়। লগ উদ্বেগজনক দেখালে এটি পরীক্ষা করার সুইচ নয়।

চক্রটি বন্ধ করুন: নকলটি তার উৎসেই সরান

কোন মালিক এন্ট্রিটি ধরে আছে তা জানার পরে যে জায়গায় নির্দেশটি সংজ্ঞায়িত সেখানেই নকল নির্দেশটি সরান। এটি প্রোফাইলের একটি route লাইন, সার্ভারের পাঠানো পুশ, বা আর চালানোর দরকার নেই এমন হুক হতে পারে।

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

তারপর আবার সংযোগ করে তিনটি বিষয় নিশ্চিত করুন: টানেল ওঠে, অভীষ্ট গন্তব্য আপনার চাওয়া পথেই সমাধান হয়, এবং ত্রুটিটি চলে যায় তার জায়গায় নতুন একটি না এসে। ভুল নির্বাচিত পথসহ পরিষ্কার লগ কোনো সমাধান নয়।

প্রিফিক্সটি যদি এক দিকে স্থানীয় LAN আর অন্য দিকে দূরবর্তী নেটওয়ার্ক বোঝায়, সমস্যাটি নকল নয় বরং ঠিকানা ওভারল্যাপ, এবং কোনো মুছুনই দুই অর্থকে একসঙ্গে সত্য করতে পারবে না। ওই ক্ষেত্রে দুটি নেটওয়ার্কের একটির জন্য আলাদা পরিকল্পনা দরকার। কোন দিকটি পুনঃসংখ্যায়িত হবে তা ঠিক করুন, তারপর যেকোনোটিকে স্পর্শ করুন।