দুটি গেটওয়ে, একটি VPN: কেন OpenVPN ভুল আপলিংক বেছে নেয়

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

টানেলের ঠিকানা শেষ বিন্দু নয়

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

প্রোফাইলের remote এন্ট্রি বাইরের গন্তব্য নির্দেশ করে, তাই এটিই পিন করতে হবে এমন ঠিকানা। এটি সেই মানও, যা হোস্টনেম ভিন্নভাবে রিজলভ হলে বা প্রোফাইলে একাধিক remote থাকলে বদলে যায়।

ক্লায়েন্ট আসলে যে ঠিকানায় ডায়াল করেছিল তা খুঁজুন

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

শেষ বিন্দু পিন করুন এবং পলিসির ক্রম পড়ুন

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

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

সেই রুট কেবল তখনই সাহায্য করে যদি লুকআপ সেই টেবিলে পৌঁছায়। পলিসি নিয়মগুলি ক্রমে মূল্যায়িত হয় এবং প্রথম মিলই সিদ্ধান্ত নেয়, তাই যে নিয়ম সবকিছু দ্বিতীয় টেবিলে পাঠায় তা main-এ আপনার হোস্ট রুটকে এড়িয়ে যায়। রুটটিকে কর্তৃত্বপূর্ণ ধরে নেওয়ার আগে নিয়মগুলি পড়ুন:

ip rule show
ip route get 203.0.113.40

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

শেষ বিন্দু সরে গেলে

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

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

ভেতরের পলিসি আলাদা রাখুন

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

লক্ষ্য যদি কেবল এনক্রিপ্টেড ট্রান্সপোর্টকে মিটারযুক্ত লিংক থেকে দূরে রাখা হয়, ডিফল্ট রুটটিকে অপরিবর্তিত রেখে একক হোস্ট ব্যতিক্রমটি যোগ করুন। একটি VPN সংযোগ সরাতে মেশিন-ব্যাপী ডিফল্ট বদলালে হোস্টের প্রতিটি অন্য অ্যাপ্লিকেশন ভেঙে যায়।

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