VPN অ্যাপ ক্র্যাশ করেছে: আপনার কিল সুইচ কি এখনও চালু?

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

প্রথমে রিবুট করবেন না; রিবুট সাধারণত প্রমাণ নষ্ট করে।

যা এখনও চলছে সেখান থেকেই শুরু করুন

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

ডিমন বেঁচে থাকলে টানেলও সম্ভবত বেঁচে আছে, আর হারানো উইন্ডোটা শুধুই বাহ্যিক।

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

ব্লকটি অ্যাপ থেকে নয়, প্রয়োগকারীর কাছ থেকে পড়ুন

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

Android এটি আরও ভিন্নভাবে সামলায়: lockdown সহ always-on VPN একটি প্ল্যাটফর্ম সেটিং, তাই ব্লকটি অ্যাপ প্রসেসের থেকে স্বাধীনভাবে টিকে থাকে, আর সিস্টেম সার্ভিসটি পুনরায় চালু করতে পারে। ডেস্কটপ ক্লায়েন্টের সাথে মেলে ধরে নেওয়ার বদলে সঠিক আচরণের জন্য প্ল্যাটফর্মের ডকুমেন্টেশন দেখুন।

সুস্থ প্রস্থান আর ক্র্যাশের পার্থক্য বুঝুন

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

এই পার্থক্যই আপনার পুনরুদ্ধার নির্ধারণ করে: সুস্থ প্রস্থানের নতুন সংযোগ লাগতে পারে, আর ক্র্যাশের ক্ষেত্রে বাকি নিয়মগুলো ক্লায়েন্টের সমর্থিত মেরামত ক্রিয়ার মাধ্যমে সরাতে হতে পারে।

অন্য নিয়ন্ত্রণ না ভেঙে পুনরুদ্ধার করুন

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

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

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