منو گزینهٔ قطع اتصال را دارد، پنجره دکمهٔ بستن دارد و مدیر وظیفه گزینهٔ پایان دادن به وظیفه را دارد. هر یک از این‌ها راهی برای متوقف کردن 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

اگر قواعد همراه با فرایند ناپدید شوند، مالکشان کلاینت بوده است. اگر قواعد بمانند در حالی که فرایند رفته است، چیز دیگری سیاست را اجرا می‌کند، و یافتن آن مؤلفه پیش از هر تغییری می‌آید. وضعیت سرویس را در همان لحظه ثبت کنید، زیرا رابط متوقف‌شده چیزی دربارهٔ یک سرویس سیستمی نمی‌گوید.

قطع اتصال دستی فروپاشی نیست

قطع اتصال مسیر خاموش‌سازی مورد نظر را اجرا می‌کند و فروپاشی آن را دور می‌زند. بنابراین نتایج یکی به دیگری منتقل نمی‌شود، پس آزمونی که از یک گزینهٔ منو استفاده کرده نمی‌تواند ادعایی دربارهٔ رفتار هنگام مرگ کلاینت را پشتیبانی کند.

به همین شکل، فروپاشی چیزی دربارهٔ یک توقف موقت تأییدشده به شما نمی‌گوید. این سه پرسش را در طرح آزمون و در هر آنچه بعداً نوشته می‌شود جدا نگه دارید. مسیر خاموش‌سازی همچنین توضیح می‌دهد که چرا یک خروج پاک می‌تواند قواعدی را که فروپاشی بر جای می‌گذارد حذف کند. همان دکمه، کد متفاوت، شواهد متفاوت.

وضعیت در دسترس نبودنی را که واقعاً لازم دارید انتخاب کنید

اگر ترافیک باید هر زمان که تونل پایین است مسدود بماند، آن شرط را در همان اقدام مشخصی که برایتان مهم است بررسی کنید و از ترافیک بی‌ضرر به مقصدی شناخته‌شده استفاده کنید. استثناهای برنامه‌ها و استثناهای شبکهٔ محلی را هم بگنجانید، زیرا اجرای فراگیر برای کل دستگاه معمولاً محدودتر از آن است که نامش القا می‌کند. سپس تأیید کنید پس از راه‌اندازی دوباره چه می‌شود، چون معمولاً همان‌وقت است که وضعیت کهنه ظاهر می‌شود.

اگر هدف دسترسی مستقیم معمولی است، از کنترل مستند استفاده کنید نه از کشتن فرایندها یا خاموش کردن کل دیوار آتش. قواعد کهنه‌ای که یک خروج قطع‌شده بر جای می‌گذارد مشکلی متفاوت از قفل‌شدن عمدی است و به بازیابی متفاوتی نیاز دارد.

بنویسید کدام مؤلفه متوقف شد: تونل، برنامهٔ قابل مشاهده، یا لایه‌ای که سیاست را اجرا می‌کند. همان یک جمله بیشتر سردرگمی‌ای را که این کنترل‌ها می‌سازند جلوگیری می‌کند.

مقالات مرتبط