למה kill switch מפיל תעבורה כשמחליפים שרת
למה kill switch חוסם תעבורה בזמן החלפת שרת, מה הלקוח עושה בחלון הזה ואיך להבדיל בין הפסקה רגילה לחסימה תקועה.
אתם בוחרים שרת שנראה קרוב יותר, לוחצים על התחברות, והדפדפן מפסיק לטעון לפני שהמנהרה החדשה עולה. הסמל עובר למצב מתחבר ונשאר שם בזמן שכל לשונית מגיעה לפסק זמן. ההפסקה הזו היא בדרך כלל ה-kill switch שעובד כמתוכנן: התעבורה חסומה כל עוד ללקוח אין מנהרה לשלוח דרכה. אם ההפסקה סבירה תלוי במה שהלקוח עושה בשניות האלה ובכך אם החסימה מוסרת כשהוא אומר שהוסרה.
מה הלקוח עושה בין שני שרתים
החלפת נקודת קצה היא כמה שלבים, לא מתג אחד. הלקוח מפרק את המנהרה הנוכחית, מעדכן את כללי החסימה שלו, מפענח את נקודת הקצה החדשה ומגיע אליה מחוץ למנהרה, ואז מתקין את המסלולים החדשים ומרים את החסימה. הפער שאתם מרגישים נמצא בין השלב הראשון לאחרון.
הסדר כאן חשוב יותר מהמהירות. אם כללי החסימה נכנסים לפני החריגה עבור נקודת הקצה החדשה, הלקוח לא יכול להשלים את לחיצת היד והוא נשאר במצב מתחבר עד לפסק זמן. אם החריגה היא העתק של כתובת השרת הישן, לחיצת היד החדשה נראית כמו כל חבילת יוצאת אחרת ונזרקת. שני המקרים נראים זהים מהדפדפן, ולכן החלפה שמתאוששת אחרי שש שניות ואחת שלעולם אינה מתאוששת יכולות לחלוק את אותה סיבה.
נקודת הקצה החדשה צריכה חור בחסימה
כדי לבנות את המנהרה, הלקוח חייב לשלוח חבילות לכתובת ולפורט של השרת החדש בממשק הפיזי, למשל UDP 51820 בפרופיל WireGuard טיפוסי או 1194 ו-443 ב-OpenVPN, כפי שהפרופיל שלכם מגדיר. התעבורה הזו אינה בתוך המנהרה שעומדת להיווצר, ולכן חסימה לכל המכשיר בולעת אותה אלא אם קיים כלל הרשאה מתאים.
פרופילים מבוססי שם מארח מוסיפים דרישה שנייה: החיפוש עצמו. אם הלקוח מפענח את נקודת הקצה לפני שהחסימה עולה, הוא יכול להשתמש בכתובת שמורה במטמון, אבל כשהפרופיל מחליף כתובות או כשהערך במטמון מתיישן, לחיצת היד פונה לכתובת שכלל ההרשאה אינו מכסה. IPv6 הופך את זה לגלוי, כי נקודת קצה כפולת מחסניות יכולה לפרסם גם רשומת A וגם רשומת AAAA, וכלל הרשאה שמכסה רק את כתובת v4 משאיר את הלקוח מנסה שוב מול כתובת v6 חסומה.
שמות האפשרויות וערכי ברירת המחדל משתנים לפי לקוח וגרסה, אז קראו את הרשימה המתועדת של הלקוח שלכם ולא נחשו מתמונות מסך. מדריך ההגדרות של OpenVPN Connect בכתובת openvpn.net/connect-docs/app-settings-windows הוא דוגמה אחת לאופן שבו לקוח מתאר את אפשרויות החסימה והמנהרה המפוצלת שלו.
Fail-closed הוא מכונת מצבים, לא מתג
רוב הלקוחות מבטאים את החסימה כמדיניות חומת אש בשלושה מצבים: מנהרה למעלה, עם תעבורה דרך המנהרה ובלי חסימה; מנהרה למטה, עם חסימה פעילה; ומעבר, עם חסימה פעילה בתוספת חריגות זמניות לנקודת הקצה. דווקא במצב השלישי חיים הבאגים, כי הוא צריך להשתנות פעמיים בתוך כמה שניות, וכישלון לצאת ממנו נראה בדיוק כמו חסימה קבועה.
המנגנון שונה לפי פלטפורמה, וכך גם הכישלון. למסנני Windows Filtering Platform יש משקלים, כך שמסנן חסימה שגובר על ההרשאה שלכם ממשיך להפיל חבילות למרות שההרשאה קיימת, ו-מסננים שהותיר תהליך לקוח שנהרג יכולים להשאיר את המכונה לא מקוונת אחרי שהאפליקציה נעלמה. לקוחות macOS כותבים בדרך כלל כללי pf בעוגן, שבו סדר הכללים והחלטות מהירות קובעים איזה כלל חל. לקוחות Linux מנהלים בדרך כלל שרשרת nftables או iptables עם מדיניות drop והרשאות מפורשות לנקודת הקצה, לממשק המנהרה ול-loopback. מצב always-on VPN של אנדרואיד עם האפשרות לחסום חיבורים בלי VPN הוא המחמיר בקבוצה, כי מערכת ההפעלה מחילה את החסימה על כל המכשיר ולא לפי אפליקציה.
WireGuard צריך הערה משלו, כי AllowedIPs הוא בורר ניתוב ולא חוסם. הוא קובע אילו יעדים נכנסים למנהרה; הוא לא עושה דבר כדי למנוע מחבילה שעוד אין לה מנהרה לצאת דרך Wi-Fi. בהגדרה של WireGuard בלבד בלי כלל חומת אש, ה-kill switch הוא למעשה היעדר מסלול, ואחרי לחיצת יד שנזרקה עשויה לצאת חבילה אמיתית דרך הממשק הפיזי.
מדדו את הפער במקום להסתכל על הסמל
עקבו אחרי חבילות, לא אחרי נורית המצב. בלינוקס התחילו פינג איטי לכתובת ציבורית במסוף אחד ולכדו את פורט התעבורה של המנהרה בממשק הפיזי במסוף אחר:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
החליפו שרת בלקוח בזמן ששניהם רצים. שלושה דברים חשובים: כמה זמן הפינגים נעצרים, אם הלכידה מראה שלחיצת היד מגיעה לנקודת הקצה החדשה, ואם התעבורה חוזרת לפני או אחרי שמצב הלקוח משתנה למחובר. אם פער הפינג נגמר ראשון, או שהחסימה הוסרה מוקדם מדי או שהמנהרה עלתה לפני שהמחוון מודה בכך. אם הפער נגמר מאוחר יותר, המחוון אופטימי מדי.
ב-Windows, netsh wfp show state כותב תמונת מצב שבה אפשר לחפש מסנני חסימה שעדיין קיימים בזמן שהלקוח טוען שהוא מנותק. ב-macOS, sudo pfctl -sr מפרט את הכללים הטעונים ואת סדרם. שלבו כל תמונת מצב עם היומן של הלקוח עצמו; ציר הזמן מהפינג שלכם אומר אם החסימה הסתיימה מאוחר או לא הסתיימה מעולם.
החשכה רגילה מול חסימה תקועה
קצת הפרעה היא כל הרעיון של התכונה, אז עשו מיון לפני שמשנים הגדרה כלשהי:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
אם אתם נוחתים בשורה השנייה או החמישית, אל תכבו את ה-kill switch כדי לבדוק, כי זה הופך באג ניתוב לדליפה. הפעילו מחדש את שירות הלקוח, או אתחלו את המכונה במקום שבו מסננים שורדים הריגת תהליך, ואז בדקו אם החסימה מתנקה. אם היא מתנקה, התקלה היא בניקוי בזמן ההחלפה ולא בחסימה עצמה.
לפני ההחלפה הבאה ודאו ארבעה דברים: הרשאת נקודת הקצה מכסה כל משפחת כתובות שהפרופיל שלכם מפענח, יומן הלקוח מראה שהמעבר הושלם, מבחן הפינג שלכם מודד את הפער ולא את הסמל, וסגירת הלקוח מחזירה קישוריות רגילה. kill switch שמחזיק במהלך ההחלפה ומשחרר אחריה עושה את עבודתו. כזה שמשחרר מוקדם, או לעולם לא, שווה דיבוג.