VPN চালু থাকা অবস্থায় অ্যাপ চলা উচিত নয়: কী এটি কার্যকর করে

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

ভ্রান্ত ধারণা: kill switch প্রোগ্রাম শুরু হওয়া আটকায়

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

যে ব্যবস্থা সত্যিই ঠিক করে একটি প্রোগ্রাম শুরু হতে পারবে কি না, তা হলো অ্যাপ্লিকেশন নিয়ন্ত্রণ। Windows-এ এর অর্থ AppLocker বা WDAC, আর ম্যানেজড macOS-এ এর অর্থ ডিভাইস প্রোফাইল দিয়ে প্রয়োগ করা অনুমোদিত তালিকা। দুটোই টানেল থেকে স্বাধীন, তাই দুই শর্ত একই টিকিটে মিলিয়ে দেওয়া হয় আর পরে কোনোটিই পূরণ হয় না।

টুলের নামের আগে মোডের নাম দিন

নিয়মটি তিন অবস্থার স্টেট মেশিন হিসেবে লিখুন: সাধারণ ব্যবহার, VPN কাজের সেশন এবং প্রস্থান। নিষিদ্ধ ওভারল্যাপ মাঝের অবস্থার, ক্লায়েন্ট সফটওয়্যারের নয়।

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

দ্বিমুখী সংঘাত আসলে কী করে

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

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

শুধু প্রথম লঞ্চ নয়, রূপান্তরগুলো পরীক্ষা করুন

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

তৃতীয় কমান্ডের অ্যাপটিকে নিষ্ক্রিয় রাখা উচিত, আর চতুর্থটির সেশন চলাকালে কেবল টানেল সংযোগ তালিকাভুক্ত করা উচিত। ভিন্ন ফল মানে রূপান্তরটি আদৌ প্রয়োগ হয় না।

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