VPN همیشهروشن یا kill switch: کدام را واقعاً فعال کردهاید؟
همیشهروشن تونل را دوباره وصل میکند؛ kill switch تعیین میکند چه چیزی بدون آن بیرون میرود. پنج بررسی پیش از باور کردن برچسب.
همیشهروشن و kill switch در همان صفحه تنظیمات فقط دو خط فاصله دارند، پس مردم آنها را دو نام برای یک ویژگی میخوانند. چنین نیست. همیشهروشن یک سیاست اتصال دوباره است: تونل را هنگام راهاندازی باز میکند، پس از خرابی یا تغییر شبکه برمیگرداند و تا وقتی ناموفق است دوباره تلاش میکند. kill switch یک سیاست ترافیک است: نام بستههایی را میبرد که میتوانند هنگام پایین بودن تونل از دستگاه خارج شوند. میتوانید اولی را بدون دومی فعال کنید و در بیشتر پلتفرمها نتیجه پیشفرض در این فاصله هنوز ترافیک را بیرون میگذارد.
بررسی 1: آیا مسدودسازی کلید خودش است؟
در Android 10 و بالاتر، پروفایل ذخیرهشده VPN پشت نماد چرخدنده دو کلید مستقل باز میکند: VPN همیشهروشن و مسدود کردن اتصالها بدون VPN. تنها دومی kill switch است. با همیشهروشن تنها، تونل پس از قطع برمیگردد، اما هر برنامهای که در میانه درخواست است تا آن زمان از Wi-Fi یا داده موبایل به شبکه میرسد.
دستگاههای مدیریتشده همین تفکیک را در API سیاستها نگه میدارند. setAlwaysOnVpnPackage() نام بسته و پرچم lockdownEnabled را میگیرد؛ مدیری که بسته را تنظیم کند و پرچم را نادرست بگذارد تونل پایداری ساخته، نه دستگاه بسته. عبارتپردازی کنسول این تفاوت را کم نشان میدهد.
وضعیت را از دستگاه بخوانید نه از کنسول: adb shell settings get global always_on_vpn_app و adb shell settings get global always_on_vpn_lockdown. اگر اولی null برگرداند، در سطح پلتفرم هیچ بستهای اجباری نیست؛ اگر دومی 0 برگرداند، پلتفرم چیزی را مسدود نمیکند. راهنمای VPN اندروید اینها را تواناییهای جدا میداند نه یک حالت.
بررسی 2: مسدودسازی مال کدام لایه است؟
برچسبها در کلاینتاند و مسدودسازیها معمولاً در دیوار آتش، پس یک واژه در هر پلتفرم معنای دیگری دارد. ردیفهای زیر پیش از اعتماد به هر یک ارزش تأیید دارند.
| Where you see the label | What the label promises | What actually blocks |
|---|---|---|
| Android VPN profile | Always-on VPN | Block connections without VPN |
| Android device policy | Always-on package | lockdownEnabled flag |
| Windows built-in VPN | Always On tunnel | Outbound firewall rules |
| WireGuard for Windows | Tunnel service | Block untunneled traffic option |
| wg-quick on Linux | Route via AllowedIPs | Your own nftables or iptables rules |
Windows روشنترین نمونه برچسبی است که مسدود نمیکند. Always On در آنجا پایداری تونل را توصیف میکند: تونل دستگاه برای احراز هویت ماشین، تونل کاربر برای حساب واردشده، که با XML پروفایل یا Add-VpnConnection تنظیم میشوند. هیچ چیز در آن پروفایل بسته خروجی را هنگام نبود تونل نگه نمیدارد، و پالایش خروجی بهطور پیشفرض روشن نیست، پس لپتاپ روی Wi-Fi در حالی که VPN پایین است کار میکند.
WireGuard هم همانگونه تقسیم میشود، اما بر پایه کلاینت. WireGuard برای Windows گزینهای برای هر تونل دارد، مسدود کردن ترافیک بدون تونل، که قواعد پالایش را نصب میکند؛ ابزارهای Linux چنین کلیدی ندارند. wg-quick برای هر ورودی AllowedIPs یک مسیر و یک قاعده fwmark اضافه میکند، و wg-quick down هر دو را برمیدارد، پس مسیر فیزیکی پیشفرض بدون افتادن بسته دوباره برمیگردد.
در پلتفرمهای Apple، همیشهروشن بهعنوان ویژگی پروفایل مدیریت برای دستگاههای تحتنظارت میآید و بهصورت قواعد درخواستی بیان میشود، نه جعبه انتخاب. پرسش از محموله این است که تونل ناموفق ترافیک را رد میکند یا فقط اتصال دیگری میخواهد. عنوان منو این را نمیگوید.
بررسی 3: شکاف را بسنجید نه نماد را
چهار گذار مهماند و هر یک بهگونهای متفاوت شکست میخورند: راهاندازی پیش از ورود کسی، خواب و بیدارشدن، تغییر Wi-Fi به داده موبایل، و فروپاشی کلاینت که رابط تونل را نیمهتنظیم رها میکند. اتصال دوباره پاک در یکی چیزی درباره سه دیگر اثبات نمیکند.
ارزانترین آزمون تونل را عمداً متوقف میکند و سپس تلاش میکند بیرون برود. با تونل پایین، curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com که 200 برگرداند یعنی سیاست fail-open است؛ پایان زمان یا اتصال ردشده یعنی چیزی هنوز مسدود میکند. ip route get 1.1.1.1 رابطی را نام میبرد که بسته را میبرد، که معمولاً بیش از نماد سینی میگوید، و systemctl status wg-quick@wg0 نشان میدهد رابط پاک برداشته شده یا نه.
همان آزمون را در پنجره دوم هنگامی که شبکه تغییر میکند اجرا کنید، نه فقط بعد از آن. فاصله میان قطع و تلاش دوباره بخش مهم است، و جستوجوی نام سریعترین راه دیدن فرار ترافیک است: اگر حلکننده محلی در حالی که تونل پایین است پاسخ دهد، مسدودسازی کامل نیست.
بررسی 4: استثناها را پیش از قفل کردن تعیین کنید
دو استثنا ساختاریاند. کلاینت باید خود سرور VPN را برسد، پس قاعدهای که همهچیز را میریزد اتصال دوبارهای را هم که حفاظت را برمیگرداند مانع میشود. درگاه اسیر هم از تونلی که بالا نیست در دسترس نیست، پس دستگاه قفلشده در Wi-Fi هتل راهی مستند برای باز کردن درگاه میخواهد، نه بداهه.
شکلی کمینه، نقطه پایانی مجاز و بقیه ریخته:
table inet vpnlock {
chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip daddr 203.0.113.10 udp dport 51820 accept
oifname "wg0" accept
}
}
با آن خط نقطه پایانی مانند متغیر رفتار کنید نه ثابت. ارائهدهندگان نشانیها را میچرخانند، و استثنای کهنه دلیل معمول تبدیل یک kill switch کارا به دستگاهی است که نمیتواند دوباره وصل شود. چاپگرهای محلی، اشتراکهای NAS و سرویسهای توسعه در همان فهرست نوشتهشدهاند، وگرنه یکییکی با بلیت پشتیبانی کشف میشوند.
بررسی 5: ثبت کنید واقعاً چه چیزی را اثبات کردید
جدولی چهارستونی نگه دارید و با آزمودن پرش کنید: وضعیت، رفتار انتظاری، رفتار مشاهدهشده، شاهد. ردیفها گذارهای بررسی 3 بهعلاوه یک شکست عمدیاند. ردیفی که با خروجی فرمان پر نمیشود ردیفی است که نیازمودهاید، و دستگاهی که ردیف اتصال دوباره را میگذراند و در ردیف راهاندازی میافتد بهقدری رایج است که ده دقیقه اضافه ارزشش را دارد.
پیش از آنکه تمامشده بنامیدش:
- تأیید کنید تنظیم مسدودسازی از تنظیم اتصال دوباره جدا است، و مقدارش را روی دستگاه بخوانید.
- بدانید کدام لایه مسدودسازی را اعمال میکند - گزینه کلاینت، سیاست دستگاه یا دیوار آتش - و کجا تنظیم میشود.
- یک فرمان آزمون نگه دارید که مسدودسازی را اثبات کند، و آن را در میانه گذار اجرا کنید نه بعد.
- فهرست استثناها را بنویسید، با نقطه پایانی، و بنویسید چه کسی آن را تازه میکند.
- روی سختافزار مدیریتشده سیاست اعمالشده را رها کنید؛ برداشتن مسدودسازی نیاز را عوض میکند نه تونل را درست.