Always-on VPN מול מתג הרג: מה בעצם הפעלתם?
Always-on VPN מחבר מחדש את המנהרה; מתג ההרג קובע מה רשאי לצאת בלעדיה. חמש בדיקות לפני שאתם סומכים על התווית.
Always-on ומתג הרג יושבים שתי שורות זה מזה באותו מסך הגדרות, ולכן קוראים אותם כשני שמות לאותה תכונה. הם לא. Always-on היא מדיניות התחברות מחדש: להעלות את המנהרה באתחול, להחזיר אותה אחרי קריסה או החלפת רשת, ולהמשיך לנסות כל עוד היא נכשלת. מתג הרג הוא מדיניות תעבורה: הוא קובע אילו מנות עדיין רשאיות לצאת מהמכונה כשהמנהרה מושבתת. אפשר להפעיל את הראשון בלי השני, ובמרבית הפלטפורמות ברירת המחדל עדיין משחררת תעבורה בזמן הפער.
בדיקה 1: האם החסימה היא מתג בפני עצמו?
ב-Android 10 ואילך, פרופיל VPN שמור נפתח לשתי אפשרויות עצמאיות מאחורי סמל גלגל השיניים: Always-on VPN ו-חסימת חיבורים ללא VPN. רק השנייה היא מתג ההרג. עם Always-on לבדו המנהרה אכן חוזרת אחרי נפילה, אבל כל אפליקציה באמצע בקשה יכולה להגיע לרשת דרך Wi-Fi או נתונים סלולריים עד שזה קורה.
מכשירים מנוהלים שומרים על אותה הפרדה ב-API המדיניות. setAlwaysOnVpnPackage() מקבל את שם החבילה ודגל lockdownEnabled; מנהל שמגדיר את החבילה ומשאיר את הדגל false בנה מנהרה מתמשכת, לא מכשיר סגור. הניסוח בקונסולה כמעט אף פעם לא מבליט את ההבדל הזה.
קראו את המצב מהמכשיר ולא מהקונסולה: adb shell settings get global always_on_vpn_app ו-adb shell settings get global always_on_vpn_lockdown. אם הראשון מחזיר null, שום חבילה לא נאכפת ברמת הפלטפורמה; אם השני מחזיר 0, הפלטפורמה לא חוסמת דבר. מדריך ה-VPN של Android מתאר את אלה כיכולות נפרדות ולא כמצב אחד.
בדיקה 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 for Windows כולל אפשרות Block untunneled traffic לכל מנהרה שמתקינה כללי סינון; בכלי ה-Linux אין מתג מקביל. wg-quick מוסיף נתיב לכל רשומת AllowedIPs ועוד כלל fwmark, ו-wg-quick down מסיר את שניהם, כך שנתיב ברירת המחדל הפיזי משתלט שוב בלי שאף מנה נפלה בדרך.
בפלטפורמות Apple, always-on מגיע כתכונה של פרופיל ניהול למכשירים בפיקוח ומבוטא ככללי on-demand ולא כתיבת סימון. השאלה שצריך לענות עליה מתוך ה-payload היא אם מנהרה שנכשלה חוסמת תעבורה או רק מבקשת חיבור נוסף. כותרת התפריט לא תספר לכם.
בדיקה 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
}
}התייחסו לשורת נקודת הקצה כמשתנה ולא כקבוע. ספקים מחליפים כתובות, וחריג מיושן הוא הסיבה הרגילה שבגללה מתג הרג עובד הופך למכשיר שלא מצליח להתחבר מחדש. מדפסות מקומיות, שיתופי NAS ושירותי פיתוח שייכים לאותה רשימה כתובה, אחרת הם מתגלים תלונה אחרי תלונה.
בדיקה 5: תעדו מה באמת הוכחתם
נהלו טבלה בת ארבעה טורים ומלאו אותה בבדיקות: מצב, התנהגות צפויה, התנהגות שנצפתה, ראיה. השורות הן המעברים מבדיקה 3 ועוד כשל מכוון אחד. שורה שאינכם יכולים למלא בפלט פקודה היא שורה שלא בדקתם, ומכשיר שעובר את שורת החיבור מחדש ונכשל בשורת האתחול נפוץ מספיק כדי להצדיק את עשר הדקות הנוספות.
לפני שאתם קוראים לזה סוף:
- ודאו שהגדרת החסימה נפרדת מהגדרת החיבור מחדש, וקראו את ערכה במכשיר.
- דעו איזו שכבה אוכפת את החסימה - אפשרות בלקוח, מדיניות מכשיר או חומת אש - והיכן היא מוגדרת.
- השאירו פקודת בדיקה אחת שמוכיחה את החסימה, והריצו אותה בזמן מעבר ולא אחריו.
- כתבו את רשימת החריגים, כולל נקודת הקצה, וציינו מי מרענן אותה.
- בחומרה מנוהלת, אל תיגעו במדיניות הנאכפת; הסרת החסימה משנה את הדרישה במקום לתקן את המנהרה.