একটি Linux হোস্টে দুটি OpenVPN টানেল: রুটের মালিক কে?

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

দ্বিতীয় লিংককে যে কাজ করতে হবে সেখান থেকেই শুরু করুন

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

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

ওভারল্যাপিং পুল রাউটিংয়ের আগেই ভেঙে পড়ে

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

স্থানীয় LAN-ও দেখুন। 192.168.1.0/24 নম্বরের একটি হোম LAN, যা একটি টানেলও উন্মুক্ত করে, একই দ্ব্যর্থতা তৈরি করে, আর উপসর্গ হলো এমন একটি হোস্টনেম যা রিজলভ হয় কিন্তু সংযোগ কখনো সম্পূর্ণ হয় না। রুটগুলো ছাপার আগ পর্যন্ত এটি নাম রিজলিউশনের ত্রুটি বলে মনে হয়।

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

প্রতিটি প্রোফাইলকে তার নিজস্ব ইউনিট আর প্রতিটি প্রিফিক্সকে একজন মালিক দিন

প্রতিটি প্রোফাইল নিজস্ব ইনস্ট্যান্স নাম ও নিজস্ব কনফিগারেশন ফাইল পায়, তাই office নামের ইনস্ট্যান্স office.conf লোড করে, আর lab নামেরটি lab.conf লোড করে। ডিরেক্টরি তালিকায় ভরসা না করে সার্ভিস ম্যানেজারের মাধ্যমে সেই ম্যাপিং নিশ্চিত করুন, কারণ একটি drop-in কোন ফাইল লোড হবে তা বদলে দিতে পারে। ম্যাপিং ভুল হলে আপনি যে প্রোফাইল চলছে না সেটিই টিউন করছেন।

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

মার্ক উত্তরগুলোকে যে ইন্টারফেস থেকে এসেছে সেখানেই রাখে

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

আরেকটি যোগ করার আগে বিদ্যমান রুলগুলো পড়ুন। পুনরাবৃত্ত প্রায়োরিটি আর ভুলে যাওয়া টেবিলই সাধারণত কারণ যাতে একটি মার্ক পলিসি একেবারেই কোনো প্রভাব ফেলছে না বলে মনে হয়।

একটি লিংক বন্ধ করে বিচ্ছিন্নতা প্রমাণ করুন

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

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

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