برنامه نباید وقتی 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. پایان جلسه را هم مستند کنید و از سرگیری عمدی را به بازکردن دوباره هر فرایندی که هنگام ورود متوقف شد ترجیح دهید. نتیجه هر گذار را در همان یادداشتی ثبت کنید که فایل‌های واحد را نگه می‌دارد.