সার্ভার বদলালে কিল সুইচ কেন ট্রাফিক আটকে দেয়

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

দুই সার্ভারের মাঝে ক্লায়েন্ট কী করে

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

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

নতুন এন্ডপয়েন্টের জন্য ব্লকে একটা ফুটো দরকার

টানেল তৈরি করতে ক্লায়েন্টকে ফিজিক্যাল ইন্টারফেস দিয়ে নতুন সার্ভারের ঠিকানা ও পোর্টে প্যাকেট পাঠাতে হয়, যেমন সাধারণ WireGuard প্রোফাইলে UDP 51820, বা OpenVPN-এ 1194 ও 443, আপনার নিজের প্রোফাইল যা-ই নির্দিষ্ট করুক। ওই ট্রাফিক যে টানেল তৈরি হতে চলেছে তার ভেতরে নেই, তাই মিলে যাওয়া পারমিট নিয়ম না থাকলে পুরো ডিভাইসজুড়ে ব্লক তা গিলে ফেলে।

হোস্টনামভিত্তিক প্রোফাইলে যোগ হয় দ্বিতীয় শর্ত: লুকআপ নিজেই। ব্লক ওঠার আগেই ক্লায়েন্ট এন্ডপয়েন্ট রিজলভ করলে ক্যাশে করা ঠিকানা ব্যবহার করতে পারে, কিন্তু প্রোফাইল ঠিকানা ঘোরালে বা ক্যাশে এন্ট্রি পুরোনো হলে হ্যান্ডশেক এমন ঠিকানার দিকে যায় যা পারমিট নিয়মে ঢাকা নেই। IPv6 এটা চোখে পড়ার মতো করে, কারণ ডুয়াল-স্ট্যাক এন্ডপয়েন্ট A ও AAAA দুটি রেকর্ডই প্রকাশ করতে পারে, আর কেবল v4 ঠিকানা ঢাকা পারমিট নিয়ম ক্লায়েন্টকে ব্লক করা v6 ঠিকানার বিরুদ্ধে বারবার চেষ্টা করতে ছেড়ে দেয়।

অপশনের নাম ও ডিফল্ট ক্লায়েন্ট ও সংস্করণভেদে আলাদা, তাই স্ক্রিনশট দেখে অনুমান না করে আপনারটির জন্য নথিভুক্ত তালিকা পড়ুন। OpenVPN Connect-এর সেটিংস রেফারেন্স openvpn.net/connect-docs/app-settings-windows হলো একটি উদাহরণ, কীভাবে একটি ক্লায়েন্ট নিজের ব্লক ও স্প্লিট-টানেল অপশন বর্ণনা করে।

Fail-closed একটি স্টেট মেশিন, কোনো সুইচ নয়

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

কার্যপ্রণালী প্ল্যাটফর্মভেদে আলাদা, ব্যর্থতাও তাই। Windows Filtering Platform ফিল্টারগুলোর ওজন থাকে, তাই আপনার পারমিটকে ছাড়িয়ে যাওয়া ব্লক ফিল্টার পারমিট থাকা সত্ত্বেও প্যাকেট ফেলে দিতে থাকে, আর মৃত ক্লায়েন্ট প্রসেসের রেখে যাওয়া ফিল্টার অ্যাপ চলে যাওয়ার পরেও মেশিন অফলাইন রাখতে পারে। macOS ক্লায়েন্ট সাধারণত pf নিয়ম একটি অ্যাঙ্করে লেখে, যেখানে নিয়মের ক্রম ও দ্রুত সিদ্ধান্ত ঠিক করে কোনটি প্রযোজ্য। Linux ক্লায়েন্ট সাধারণত drop নীতিসহ nftables বা iptables চেইন চালায় এবং এন্ডপয়েন্ট, টানেল ইন্টারফেস ও লুপব্যাকের জন্য স্পষ্ট পারমিট দেয়। Android-এর always-on VPN-এ VPN ছাড়া সংযোগ ব্লক করার অপশনটি দলের মধ্যে সবচেয়ে কঠোর, কারণ অপারেটিং সিস্টেম ব্লকটি অ্যাপভিত্তিক নয়, পুরো ডিভাইসে প্রয়োগ করে।

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

আইকন দেখার বদলে ফাঁকটা মাপুন

স্ট্যাটাস বাতি নয়, প্যাকেট দেখুন। Linux-এ একটি টার্মিনালে কোনো পাবলিক ঠিকানায় ধীর ping শুরু করুন এবং অন্যটিতে ফিজিক্যাল ইন্টারফেসে টানেলের ট্রান্সপোর্ট পোর্ট ক্যাপচার করুন:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

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

Windows-এ netsh wfp show state একটি স্ন্যাপশট লেখে, যেখানে ক্লায়েন্ট নিজেকে বিচ্ছিন্ন দাবি করলেও এখনো থাকা ব্লক ফিল্টার খোঁজা যায়। macOS-এ sudo pfctl -sr লোড করা নিয়ম ও তাদের ক্রম তালিকাভুক্ত করে। যেকোনো স্ন্যাপশট ক্লায়েন্টের নিজের লগের সাথে মিলিয়ে দেখুন; আপনার ping-এর সময়রেখা বলে দেবে ব্লক দেরিতে শেষ হয়েছে, নাকি কখনোই হয়নি।

স্বাভাবিক কালো আউট বনাম আটকে যাওয়া ব্লক

কিছুটা বাধা এই সুবিধারই উদ্দেশ্য, তাই যেকোনো সেটিং বদলানোর আগে শ্রেণিবিন্যাস করুন:

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

পরেরবার বদলানোর আগে চারটি বিষয় নিশ্চিত করুন: এন্ডপয়েন্ট পারমিট আপনার প্রোফাইল যে-সব অ্যাড্রেস ফ্যামিলি রিজলভ করে সবগুলো ঢাকে, ক্লায়েন্ট লগ রূপান্তর শেষ হওয়া দেখায়, আপনার ping পরীক্ষা আইকন নয় ফাঁক মাপে, আর ক্লায়েন্ট বন্ধ করলে স্বাভাবিক সংযোগ ফেরে। যে কিল সুইচ বদলের সময় ধরে রাখে আর পরে ছেড়ে দেয়, সে-ই নিজের কাজ করছে। যে আগেভাগে ছাড়ে, বা কখনোই ছাড়ে না, সেটি ডিবাগ করার যোগ্য।