কেন একটি দ্বিতীয় VPN টানেল প্রথমটি ভেঙে দেয়?

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

লক্ষণ: দ্বিতীয় ক্লায়েন্ট নীরবে জিতে যায়

OpenVPN: redirect-gateway def1 অপশনটি 0.0.0.0/0-কে প্রতিস্থাপন করে না। এটি 0.0.0.0/1 এবং 128.0.0.0/1 যোগ করে: একসাথে তারা প্রতিটি IPv4 ঠিকানা ঢেকে রাখে, আর প্রতিটি প্রিফিক্স দৈর্ঘ্যে সাধারণ ডিফল্টকে হারায়। মূল ডিফল্ট টেবিলে থেকে যায় এবং সাধারণ ট্র্যাফিকের জন্য ব্যবহৃত হওয়া বন্ধ করে, আর VPN সার্ভারের হোস্ট রুট টানেলটিকে তার নিজের বাইরের প্যাকেট ধরে ফেলা থেকে বিরত রাখে। দুটি ক্লায়েন্টই এটি করে, আর দ্বিতীয়টি শুধু তার জোড়াটি পরে ইনস্টল করে।

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

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

কোন টানেল আসলে জেতে তা পড়ুন

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

উইন্ডোজ: একটি প্রোফাইলকে ডিফল্টের মালিক হওয়া থেকে থামান

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

লিনাক্স: দ্বিতীয় টানেলকে প্রধান টেবিলের বাইরে রাখুন

একই মেশিনে দুটি openvpn --config ইনস্ট্যান্স চালালে দুটি ক্লায়েন্টই একই টেবিলে পড়ে, আর তিনটি বিকল্প ক্রমবর্ধমান বিচ্ছিন্নতায় তাদের আলাদা করে। সবচেয়ে হালকা হলো দ্বিতীয় ক্লায়েন্টকে টেবিল সম্পাদনা থেকে সম্পূর্ণ বিরত রাখা: স্পষ্ট রুটসহ route-nopull, অথবা route-up স্ক্রিপ্ট যা শুধু আপনার ইচ্ছাকৃতটুকু ইনস্টল করে। তখন দ্বিতীয় টানেল ঠিক আপনার নামানো প্রিফিক্সগুলোই বহন করে, আর কিছুই নয়। তখন কোন প্রিফিক্স কোথায় যাবে আপনি ঠিক করেন, পরে আবিষ্কার করেন না।

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

নেটওয়ার্ক নেমস্পেস সবচেয়ে ভারী এবং সবচেয়ে পরিষ্কার বিকল্প। দ্বিতীয় ক্লায়েন্টকে ip netns-এর ভেতরে চালু করুন, একটি veth জোড়া দিন, এবং ব্যবহার করতে সেই নেমস্পেসে ঢুকুন। হস্তক্ষেপ উধাও হয় কারণ প্রতিটি নেমস্পেস একটি টেবিল ভাগ করার বদলে নিজের টেবিল রাখে; দুটি টানেল সপ্তাহের পর সপ্তাহ চালু থাকতে হলে এই বাড়তি সেটআপ সার্থক।

প্রতি-অ্যাপ্লিকেশন, এবং চেইনিং আলাদা সমস্যা হিসেবে

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

চেইনিং দুটি টানেল পাশাপাশি চালানোর চেয়ে ভিন্ন কাজ। A-কে B-এর উপর দিয়ে চেইন করা মানে ভেতরের সার্ভারের ঠিকানা বাইরের টানেলের ভেতর থেকে পৌঁছানোযোগ্য হতে হবে। বাইরের ক্লায়েন্টও ভেতরের ক্লায়েন্টের এনক্রিপ্ট করা প্যাকেটকে লিক ভাববে না। ভার্চুয়াল মেশিনের ভেতরে একটি ক্লায়েন্ট হলো মোটা কিন্তু নির্ভরযোগ্য সংস্করণ; একই হোস্টে দুটিই থাকলে উপরোক্ত রাউটিং কাজের সঙ্গে ভেতরের সার্ভারের দিকে বাইরের এমন পথ লাগবে যা কখনো ভেতরের টানেলে ঢোকে না।

ডিফল্টের মালিক, প্রতিটি টানেলের বহন করা প্রিফিক্স তালিকা এবং DNS পথ লিখে রাখুন। এই তিনটি তথ্য পরের ঘটনাটিকে তদন্তের বদলে খোঁজে পরিণত করে।