מתג ההרג ממשיך לחסום תעבורה לאחר התנתקות ה-VPN

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

מתג הרג הוא מצב ליבה, לא הגדרה

לקוחות שולחן העבודה מיישמים חסימה על ידי הוספת מסננים שדוחים תעבורה מחוץ למנהרה. ב-Windows אלה מסנני WFP בשכבות הפניית החיבור והתעבורה, וחלקם מתמידים: הם נרשמים במאגר המדיניות של Base Filtering Engine ומשוחזרים באתחול המכונה, לפני שכל תוכנת VPN פועלת. הלקוחות שונים בזמן הניקוי. חלקם מסירים מסננים בניתוק, חלקם רק ביציאה נקייה, וחלקם רק כשמכבים קודם את מתג ההרג. הסירו את ההתקנה כשהחסימה פעילה, או הרגו את התהליך, והמסננים נשארים.

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

קראו את מצב WFP לפני שמוחקים משהו

Windows מגיע עם הכלים שצריך. הריצו שורת פקודה מוגברת ושפכו את מצב הפלטפורמה; הפלט נשמר כ-wfpstate.xml בתיקיית העבודה.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

חפשו ב-XML את שם הספק שעזב, פעולת Block ואת השכבה. מסננים בהפניית החיבור ובתעבורה הם אלה ששוברים תעבורה רגילה; מסנן בשכבת קליטת קבלה אינו הסיבה שלכם בדרך כלל. אם Base Filtering Engine לא פועל כלל, חפשו במקום אחר, כי שום דבר אחר לא יכול לאכוף את המסננים האלה.

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

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

קראו את כללי Linux בתחביר שאיתו תמחקו

iptables -S מדפיס כללים באותה צורה שבה משתמשים כדי להוסיפם, מה שהופך את הפלט לשימוש חוזר ישיר למחיקה. iptables -L -v -n מוסיף מוני מנות, והמונים האלה אומרים לכם אם כלל באמת מתאים לבקשות שנכשלו או שהוא רק יושב בשרשרת.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

קראו את מדיניות השרשראות, לא רק את הכללים: -P OUTPUT DROP חוסם תעבורה גם כשאף כלל לא מתאים. בדקו IPv6 בנפרד, כי לקוח שמתקין את שתי המשפחות עשוי להשאיר את חסימת IPv6 במקומה לאחר שכללי IPv4 נעלמו, והתסמין תלוי אז במשפחה שהאפליקציה מעדיפה. במקום שבו משתמשים ב-nftables, הריצו גם nft list ruleset; שני הכלים מתקיימים במשותף דרך שכבת תאימות, ורישום אחד לא בהכרח מציג כל כלל שיכול להשליך מנה.

מחקו את האובייקט הצר ביותר שמסביר את התקלה

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

מסננים מתמידים הם המוצא האחרון. הם יושבים תחת HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, ערך אחד לכל מסנן עם מפתח GUID. ייצאו קודם את המפתח, תעדו את מזהי ה-GUID שאתם מסירים, מחקו רק את הערכים ששייכים ללקוח שעזב, ואז אתחלו כדי שהמנוע יבנה מחדש את מצבו. אל תמחקו את כל המפתח ואל תשביתו את Base Filtering Engine: חומת האש של Windows ו-Defender תלויים בו, והייתם מחליפים תקלה באחת גרועה יותר.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

ב-Linux, קחו את השורה ש-iptables -S מדפיס והחליפו את -A ב--D. מחיקת הכלל האחד שזיהיתם עדיפה על ריקון שרשרת, כי היא משאירה את המדיניות שלכם שלמה.

sudo iptables -D OUTPUT -p udp -j REJECT

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

מצאו את הבעלים שמחזיר אותו

לאחר התיקון המיידי, חפשו כל דבר שיכול לשחזר את המצב. ב-Linux בדקו אם יחידת התמדה מופעלת, אם ללקוח יש הגדרה לשחזור חומת האש בכניסה, ואם קיים קובץ כללים שמור תחת /etc. ב-Windows בדקו שוב ערכי אתחול, שירותים ומשימות מתוזמנות, ואז אתחלו וקראו שוב את המצב עם אותן פקודות כמו קודם.

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

אמתו בתעבורה אמיתית, לא בפינג אחד

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

שמרו את הראיות: מפתח ה-BFE שיוצא, או פלט iptables -S שנלכד לפני השינוי. לפני שאתם קוראים לזה מתוקן, אשרו את השכבה שממנה הסרתם את האובייקט, את הבעלים שיכול היה להתקין אותו מחדש, את המצב לאחר אתחול נקי אחד, ושגלישה רגילה עובדת בלי שום תהליך VPN פועל. בדף המדריך iptables(8) יש את תחביר המחיקה והמדיניות המדויק אם אתם כותבים סקריפט לניקוי.