מתג הרג באפליקציה מול מתג הרג בחומת האש: מה כל אחד חוסם

מתג הרג ברשימת תכונות לא אומר לכם כמעט דבר על מה שקורה כשהמנהרה נופלת. מימוש אחד סוגר תהליכים נבחרים, אחר מתקין מסנני מנות בגבול מערכת ההפעלה, ושלישי פשוט מנסה להתחבר מחדש. ההבדל נראה בשניות שאחרי כשל, לא במסך ההגדרות. עברו על הבדיקות האלה לפי הסדר ועצרו בראשונה שאין לכם תשובה כנה עבורה, כי שם נגמר הכיסוי האמיתי שלכם.

קודם כל תנו שם למנגנון האכיפה

סיום תהליכים הוא תכונה של מחזור החיים של האפליקציה. הוא מאתר תוכניות נבחרות לאחר כשל מנהרה שזוהה וסוגר אותן. כל מה שאינו התהליך הראשי שורד: שירותי עזר, סנכרון ברקע וכל אפליקציה שתופעל שנייה לאחר מכן, לכל אחד מחזור חיים ותזמון משלו.

סינון מנות הוא תכונה של מערכת ההפעלה. הוא מסרב לתעבורה שאינה הולכת במסלול המותר, שזו הבטחה חזקה יותר, אבל רק עד כמה שהכלל תואם בפועל. משפחת הכתובות, הממשק, האפליקציות המוחרגות והחריגים קובעים זאת, ולא התווית בלקוח.

האם החסימה שורדת את הלקוח?

שאלו ארבע שאלות לפי הסדר הזה: מה קורה בקריסה, ביציאה ידנית, בהתנתקות ובאתחול מחדש. כלל שהלקוח עצמו מתחזק מוסר בדרך כלל בכיבוי מסודר ולעיתים קרובות נשאר אחרי קריסה. כלל שמותקן במאגר הפלטפורמה יכול להתנהג הפוך: לשרוד גם את הלקוח ולפעמים גם את ההסרה.

סגרו את הלקוח באמצע הורדה ארוכה ובדקו אם ההעברה נעצרת או ממשיכה.

חפשו את החורים הרגילים

IPv6 הוא הראשון. כלל שנכתב לכתובות IPv4 משאיר את תעבורת IPv6 בלי פגע, והרבה לקוחות כותבים רק את חצי v4. השני הוא הממשק: שיתוף חיבור USB, מתאם Wi-Fi נוסף ומודם סלולרי עשויים שלא להיכלל בכלל שמוגבל לחיבור הראשי. אפליקציות מוחרגות וחריגי רשת מקומית הם השלישי.

ב-Windows אפשר לקרוא את הכללים המותקנים במקום לסמוך על המתג: Get-NetFirewallRule -DisplayName '*VPN*' ו-netsh wfp show filters שניהם מראים מה קיים. ב-Linux ‏iptables -S, ip6tables -S ו-nft list ruleset מכסים את המקרים הנפוצים, והשוואה בין שלושתם היא העיקר.

DNS הוא הדליפה הרגילה

חסימת TCP כשמשאירים את UDP 53 פתוח נותנת לכם מתג הרג משכנע מאוד שעדיין עונה לכל שאילתת שם מארח. כך גם כשמעבירים את DNS לפותרן בממשק אחר, או כשהלקוח חוסם רק v4 והפותרן נגיש דרך v6.

כשהמנהרה למטה, פתרו שם מוכר אחד וראו אם חוזרת תשובה. אם כן, התעבורה אינה חסומה לגמרי, יאמר מה שיאמר סמל המצב.

בדקו את המעבר, לא את המתג

כיבוי ה-VPN מהתפריט שלו הוא כיבוי מסודר, והמקרה המסודר הוא זה שכל מימוש מטפל בו היטב. המעבר שמשנה הוא הגס: הרגו את תהליך המנהרה, נתקו את הרשת, תנו לשרת להפסיק לענות. אז התחילו בקשה וראו אם היא נכשלת או משתמשת בשקט בקישור הפיזי.

תוצאה ממחשב נייד אחד לא עוברת לטלפון או לנתב. ממשקי API שונים לפלטפורמה, ברירות מחדל שונות, ובאנדרואיד ההבדל חד: מצב always-on עם חסימה נאכף על ידי המערכת ולא על ידי הלקוח, ולכן הוא ממשיך לעבוד כשהלקוח לא. מדריך ה-VPN של Android מתאר את החלוקה הזו.

השאירו דרך חזרה

לחסימה ברמת המערכת יש מצב כשל הפוך. מסננים ששורדים את הלקוח עלולים להשאיר מחשב בלי רשת כלל לאחר הסרה, וזו קריאת תמיכה בלי סיבה ברורה. לפני הפעלת מתג הרג שכותב כללי פלטפורמה, רשמו כיצד הוא מוסר, ושמרו את נתיב התיקון של היצרן במקום שתוכלו למצוא אותו.

אם אין לכם תשובה לבדיקות הקריסה, IPv6, DNS והמעבר עבור הלקוח שלכם, התייחסו אליו כמתג ברמת האפליקציה עם חורים ידועים ותכננו בהתאם.