מתג נפילה ב-Windows בלי תוכנה נוספת: פרופילים או נתיבים?

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

שתי שיטות שוות היכרות. הן נכשלות במקומות שונים, ואף אחת מהן אינה תשובה שלמה.

שיטה ראשונה: לאפשר לתוכנית בפרופיל אחד בלבד

חומת האש של Windows מגבילה כללים לפרופילים Domain, Private ו-Public. הטריק הוא לתת למתאם המנהרה קטגוריה אחת ולמתאם הפיזי קטגוריה אחרת. אחר כך כותבים כלל יוצא שמאפשר את התוכנית המוגנת בפרופיל המנהרה וחוסם אותה בכל מקום אחר. חומת האש קוראת את הקטגוריה, לא את שם המתאם.

תחילה הגדירו את חיבור ה-VPN ל-Private ואת הרשת הפיזית ל-Public. אחר כך הוסיפו כלל חסימה לתוכנית שחל על הפרופילים שאינכם רוצים. לאחר מכן אשרו את ההקצאה עם Get-NetConnectionProfile, מפני שהכלל עוקב בדיוק אחר ההקצאה הזו.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

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

שיטה שנייה: להסיר את נתיב ברירת המחדל הפיזי

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

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

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

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

שיטה שלישית: בלי שער, נתיב מארח קבוע אחד

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

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

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

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

למה סמל הגלובוס לא מוכיח דבר

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

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

מה לתעד אחרי נפילה אמיתית

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

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

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

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