একটি Linux গেটওয়েতে দুটি OpenVPN ক্লায়েন্ট: নীতি ভাগ করুন

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

কার্নেল ঠিক করে, ডেমন নয়

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

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

প্রতিটি ইনস্ট্যান্সকে নিজের সম্পদের সেট দিন

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull সার্ভারের পাঠানো রুটগুলো স্থানীয় টেবিলের বাইরে রাখে, নীতির টেবিলগুলো স্পষ্ট হওয়ার কথা থাকলে ঠিক এটাই চান। নির্দিষ্ট সার্ভার redirect-gateway অপশনও পাঠায় কি না, এবং আপনার ক্লায়েন্ট সংস্করণ ফিল্টার রূপটি সমর্থন করে কি না, তা অনুমান না করে ম্যানুয়ালে দেখে নেওয়া ভালো।

ম্যাট্রিক্স লিখুন: উৎস, টেবিল, ডিভাইস

প্রতিটি ক্লায়েন্ট গ্রুপের জন্য উৎস ঠিকানা দিয়ে টেবিল বাছাই করা একটি নিয়ম যোগ করুন, তারপর সেই টেবিলে ইচ্ছাকৃত পথটি রাখুন:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

টানেলের নিজের পরিবহন ক্লায়েন্ট গ্রুপে নেই

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

স্থানীয় ব্যবস্থাপনা সেশন ও আন্ডারলে পথকে নীতির টেবিলের বাইরে স্পষ্টভাবে রাখুন। ওই ব্যতিক্রমগুলো ম্যাট্রিক্সের পাশে লিখুন; সেগুলো নকশার অংশ, কোনো ঘটনার সময় নতুন করে আবিষ্কার করার কাজ নয়।

পথ বাছাই করা তার অনুমতি দেয় না

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

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

একটি টানেল পড়ে গেলে কী হয়

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

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