প্রস্থান নাকি সংযোগ বিচ্ছিন্ন: VPN-এ দুটি ভিন্ন ফলাফল

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

ক্লায়েন্টের ডকুমেন্টেশনই একমাত্র নির্ভরযোগ্য জায়গা যেখানে জানা যায় কোনটি কী।

চারটি নিয়ন্ত্রণ, সম্ভবত চারটি আচরণ

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

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

সার্ভার প্রান্তের বিভ্রাট পুরোপুরি পঞ্চম পথ, এবং ব্যবহারকারীরা সবচেয়ে বেশি যে পথে পড়েন সেটি এটিই।

প্রতিটি কাজের আগে ও পরে অবস্থা পড়ুন

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

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

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

হাতে সংযোগ বিচ্ছিন্ন করা ক্র্যাশ নয়

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

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

আপনার সত্যিই যে অনুপলব্ধ অবস্থা দরকার সেটি বেছে নিন

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

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

কোন উপাদান থেমেছে তা লিখে রাখুন: টানেল, দৃশ্যমান অ্যাপ্লিকেশন, নাকি নীতি প্রয়োগকারী স্তর। ওই একটি বাক্য এই নিয়ন্ত্রণগুলো যে বিভ্রান্তি তৈরি করে তার বেশিরভাগ রোধ করে।