دو برنامه VPN همزمان: کدام kill switch واقعاً اعمال می‌شود؟
کلاینت دوم VPN هرگز kill switch کلاینت اول را به ارث نمی‌برد. سه شرط تعیین می‌کند کدام سیاست اعمال می‌شود و چگونه سیاست خود را بررسی کنید.
دو کلاینت VPN می‌توانند کنار هم کار کنند، اما kill switch آن‌ها در یک سیاست واحد ادغام نمی‌شود. هر کلاینت قواعدی برای تونل خودش نصب می‌کند و هیچ‌کدام نمی‌داند که دیگری وجود دارد. من این را با یک کلاینت کاری که اول متصل بود تجربه کردم: برنامه دوم نتوانست دست‌دادن را کامل کند، ده دقیقه روی «Connecting» ماند و تونل اول همه‌چیز را بی‌صدا حمل کرد. اینکه برنامه دوم محافظت شود به سه شرط بستگی دارد، نه به اینکه هر دو نماد بگویند متصل.
kill switch واقعاً به چه چیزی محدود است
هیچ چیز در سیستم‌عامل یک پرچم kill switch واحد ندارد. کلاینتی که چنین چیزی را تبلیغ می‌کند مجموعه‌ای از قواعد نصب می‌کند: هر چیزی که از تونل من بیرون نمی‌رود را بینداز، و اغلب وقتی تونل ناپدید می‌شود fail closed عمل کن. در Linux معمولاً زنجیره nftables یا iptables است، در Windows مجموعه‌ای از فیلترهای Windows Filtering Platform، در Android و iOS مسیریابی خود سرویس تونل به‌همراه تنظیم سیستم که اتصال‌های بدون VPN را مسدود می‌کند. راهنمای VPN اندروید این مدل سرویس را توصیف می‌کند اگر دیدگاه پلتفرم را می‌خواهید.
دامنه همان بخش مهم است. قاعده‌ای مانند «فقط بسته‌های روی رابط خروجی wg0 را اجازه بده» اهمیتی نمی‌دهد که تونل دوم وجود دارد یا نه. اگر کلاینت دیگری wg1 را بالا بیاورد، قواعد کلاینت اول آن بسته‌ها را ترافیک عادی می‌دانند: معمولاً دور ریخته می‌شوند، گاهی اجازه می‌یابند. در هر حال کلاینت اول تصمیم می‌گیرد و هیچ تصوری ندارد که برنامه دوم منتظر است.
سه شرطی که تعیین می‌کند چه کسی پوشش می‌یابد
لازم نیست هر ترکیبی را بشمارید. سه پرسش آن را در چند دقیقه روشن می‌کند.
- آیا پلتفرم اصلاً تونل دوم را اجازه می‌دهد؟ بیشتر گوشی‌های Android و iPhone برای هر نمایه کاربر فقط یک سرویس VPN فعال می‌پذیرند، پس برنامه دوم هرگز تونلی ندارد و هیچ چیزی را اعمال نمی‌کند. یک سیاست می‌گیرید، از برنامه‌ای که جایگاه را برد.
- کدام فرایند مالک مسیر پیش‌فرض است؟ Windows، macOS و Linux به‌راحتی دو تونل را حمل می‌کنند. مسیر پیش‌فرض از آن کلاینتی است که آن را آخر از همه یا با متریک بهتر تنظیم کرده، و کلاینت دیگر متصل اما بی‌کار است. در Linux حالت مسیر پیش‌فرض wg-quick از مسیریابی مبتنی بر سیاست با جدول خصوصی و قاعده fwmark استفاده می‌کند، بنابراین تونل دوم wg-quick به‌جای جایگزینی اولی یک قاعده رقیب اضافه می‌کند.
- آیا کلاینت دوم به سرور خودش می‌رسد؟ اگر kill switch اول رد پیش‌فرض باشد، نقطه پایانی بیرونی برنامه دوم فقط یک مقصد دورریخته دیگر است. بی‌صدا دوباره تلاش می‌کند و هرگز خطایی گزارش نمی‌کند.
نسخه کوتاه، برای رشته‌های پشتیبانی:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
دو سطر از آن سطرها از نماد سینی سیستم یکسان به نظر می‌رسند، و به همین دلیل نماد بدترین شاهد موجود در اینجا است.
چه چیزی اول شکست می‌خورد و چگونه به نظر می‌رسد
کلاینتی که روی «Connecting» گیر کرده در حالی که دیگری سالم است تقریباً همیشه گرسنگی نقطه پایانی است: kill switch فعال دست‌دادن کلاینت دوم به سرور خودش را دور می‌ریزد. این را ارزان تأیید کنید با متوقف کردن موقت قواعد مسدودسازی کلاینت اول برای یک تلاش. اگر دومی فوراً متصل شود، پرسش پاسخ گرفته است.
DNS شکست دوم است. کلاینت‌ها پیکربندی حل‌کننده را برای رابط خود تنظیم می‌کنند و برخی فهرست جهانی را یکسره بازنویسی می‌کنند. با بالا بودن هر دو تونل، پرسش‌ها می‌توانند از یک سو بیرون بروند در حالی که حل‌کننده به سوی دیگر تعلق دارد. یکی از برنامه‌ها را قطع کنید و بازمانده یک سرور نام دست‌نیافتنی نگه می‌دارد: صفحه‌ها یک دقیقه گیر می‌کنند و بعد دوباره حل می‌شوند، در حالی که VPN همچنان متصل نشان می‌دهد.
سومی نوسان مسیرها است. اتصال‌های دوباره مسیر پیش‌فرض را بازچینش می‌کنند و kill switch متصل به رابط از آن پیروی نمی‌کند. ترافیکی که لحظه‌ای پیش در تونل بود اکنون با قاعده دورریز مطابقت دارد، که از دید کاربر مانند VPNی خوانده می‌شود که تصادفاً از کار می‌افتد.
بررسی کنید کدام سیاست واقعاً در جریان است
این کار را با ترافیک بی‌خطر انجام دهید، نه با چیزی که دلتان برایش تنگ می‌شود.
در Linux از هسته بپرسید چه کسی برنده است و دیوار آتش به چه چیزی گره خورده. ip -4 route show default تونلی را نام می‌برد که مالک خروج است. ip rule show نشان می‌دهد آیا مسیریابی مبتنی بر سیاست در جریان است. sudo nft list ruleset | grep -n oifname نشان می‌دهد آیا دورریزها به نام رابط، نشانه یا کل زنجیره خروج گره خورده‌اند.
در Windows همان داستان در متریک مسیر و فهرست فیلترها زندگی می‌کند: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric و Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". در macOS، netstat -rn -f inet | head -5 و scutil --dns | head -20.
سپس همان گامی را بردارید که مردم رد می‌کنند: تونل را عمداً متوقف کنید و تأیید کنید ترافیکی که انتظار شکستش را دارید واقعاً شکست می‌خورد. نماد متصل یک وضعیت رابط است، نه اعمال قاعده.
چه زمانی دو کلاینت طراحی غلط است
اگر تنها نیاز پشت برنامه دوم محافظت بیشتر است، آن را بردارید. دو سیاست مسدودسازی متعامل از یکی کم‌پیش‌بینی‌ترند و هر اتصال دوباره فرصتی است برای افتادن در وضعیتی که هیچ فروشنده‌ای آزمون نمی‌کند.
اگر واقعاً به زنجیره‌سازی نیاز دارید، مثلاً دروازه سازمانی که از طریق یک جهش تجاری در دسترس است، طرحی با یک نقطه اعمال انتخاب کنید. این معمولاً یعنی یک روتر یا یک کلاینت که زنجیره را پشتیبانی می‌کند، نه دو برنامه رومیزی که بر سر یک مسیر پیش‌فرض رقابت می‌کنند. روی دستگاه مدیریت‌شده کلاینت مجاز را نگه دارید و هر چیز دیگر را خارج از دامنه بدانید، هر چه در سینی نشان دهد.
چک‌لیست پیش از نگه داشتن هر دو
فهرست را به ترتیب پیش ببرید؛ اولین موردی که شکست می‌خورد همان است که باید اصلاح شود.
- تأیید کنید که دقیقاً یک کلاینت مالک مسیر پیش‌فرض و حل‌کننده است.
- اگر کلاینت دوم را بالا می‌خواهید، نقطه پایانی سرورش را صریحاً اجازه دهید و پس از هر به‌روزرسانی کلاینت دوباره بررسی کنید.
- نتیجه مورد انتظار را وقتی هر یک از تونل‌ها می‌افتد بنویسید و همان حالت را آزمون کنید.
- مسیر خرابی را پس از راه‌اندازی دوباره بررسی کنید، وقتی ترتیب شروع متفاوت است.
- روی نمایه مدیریت‌شده بایستید و پیش از افزودن هر چیزی از مالک بپرسید.
اگر گام سوم شکست بخورد، پاسخ صادقانه این است که تنها یک کلاینت به شما سیاست می‌دهد. تصمیم بگیرید به کدام اعتماد دارید و دیگری را رها کنید.