חומת האש של Windows לבדה כמתג חירום של VPN: האם היא מחזיקה?
כללי סוג ממשק יכולים לחסום את המתאמים הפיזיים, אבל מנהרה של צד שלישי נראית לרוב כחוטית. בדקו את הסיווג, את המסלול לנקודת הקצה ואז DNS.
שאלו אם חומת האש של Windows יכולה לשמש לבדה כמתג חירום ותקבלו שתי תשובות בטוחות וסתירות. האחת אומרת שכלל סוג הממשק עושה את כל העבודה; השנייה אומרת שזה לא עובד בלי סקריפטים. שתיהן מתארות חצי מאותו מנגנון. חומת האש יכולה לבטא את החסימה, והאם התוצאה באמת נכשלת סגורה תלוי בשלושה דברים: איך Windows מסווג את מתאם המנהרה, אם החריגה לנקודת הקצה שורדת, ואם תרגום שמות ו-IPv6 מכוסים. טעות באחד מהם והמכונה או מדליפה או מאבדת כל קישוריות.
שלושה תנאים, בסדר הזה
התנאי הראשון הוא הסיווג, והוא קובע אם הכלל שאתם רוצים בכלל ניתן לביטוי. כללי חומת האש של Windows ניתנים להגבלה לפי סוג ממשק: חוטי, אלחוטי או גישה מרחוק. מדיניות שחוסמת תעבורה יוצאת בסוגים הפיזיים ומתירה את המנהרה עובדת רק אם Windows מזהה את המנהרה כגישה מרחוק.
התנאי השני הוא החריגה לנקודת הקצה. לפני שקיימת מנהרה, הלקוח חייב להגיע לשרת ה-VPN דרך המתאם הפיזי, כך שחסימה גורפת על אותו מתאם מונעת בדיוק את החיבור שהיה הופך את החסימה למיותרת. החריגה חייבת לנקוב בשם השרת ובפורט שלו, והמנותב חייב לצאת דרך השער הפיזי ולא אל תוך מנהרה שעוד לא עלתה.
השלישי הוא הכיסוי. מערכת כללים שחוסמת IPv4 ושוכחת IPv6, או שמתירה למתרגם המקומי לחפש את נקודת הקצה ובכך מתירה כל חיפוש אחר, נכשלת פתוחה בדיוק בחלון שלמענו קיים מתג החירום. זה פער בתכנון ולא תקלה בחומה. זה גם הפער ששורד כל בדיקה על שולחן.
הסיווג הוא השער הראשון
בדקו מה Windows חושב על המתאמים לפני שתכתבו כלל אחד. חיבור VPN מקורי של Windows מופיע בדרך כלל כגישה מרחוק. לקוח צד שלישי שיוצר מתאם וירטואלי משלו מופיע לעתים קרובות כחוטי, כלומר חסימה המוגבלת למתאמים חוטיים חוסמת גם את המנהרה.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionהפקודה השלישית אומרת לכם אם חסימת יציאה כברירת מחדל כבר בתוקף, מה שמשנה את כל צורת התכנון. אם ברירת המחדל היא כבר חסימה, אתם כותבים כללי היתר ולא חריגים לבסיס מתירני, וזו עמדה הרבה יותר קלה לנימוק.
אם מתאם המנהרה שלכם מדווח כחוטי, חומת אש לבדה אינה הכלי הנכון לתכנון שנכשל סגור, ושום כוונון כללים לא משנה זאת. זה המקרה שבו הדעה השנייה בכל שרשור פורום היא הנכונה.
החריגה לנקודת הקצה זקוקה למסלול ולא רק לכלל
נניח שהסיווג עובד. החריגה מורכבת משני חלקים, והם חיים בתת-מערכות שונות. כלל חומת האש מתיר את התעבורה; מסלול המארח מוציא אותה דרך הממשק הנכון בזמן שהמנהרה למטה.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32בלי המסלול, החריגה עוזרת רק כל עוד מסלול ברירת מחדל עדיין מצביע לשער הפיזי. ברגע שהלקוח מתקין מסלול ברירת מחדל משלו ואז מת, לחבילות המותרות אין לאן ללכת באופן הגיוני ולא ניתן להקים את החיבור מחדש. הכשל הזה נראה כמו לקוח שבור ולמעשה הוא מסלול חסר.
השאירו את החריגה צרה ככל שהלקוח מאפשר. כתובת אחת ופורט אחד ניתנים לבדיקה; טווח שמכסה את כל הרשת של הספק לא. הכלל הרחב הזה מתיר גם כל דבר אחר שמתארח אצל אותו ספק, וזה בדרך כלל יותר ממה שהתכוונתם.
DNS ו-IPv6 הם המקום שבו זה נכשל פתוח
תרגום שמות הוא הדליפה הקלאסית. אם נקודת הקצה היא שם מארח, הלקוח חייב לפתור אותו לפני שהמנהרה קיימת, כלומר חייבים להתיר למתאם הפיזי להגיע למתרגם. אותה הרשאה מוציאה כל חיפוש אחר בזמן שהמנהרה למטה, וחיפוש אחד מספיק כדי לחשוף מה עמדתם לבקר.
IPv6 הוא השני. כללים שנכתבו ל-IPv4 אינם מכסים את המשפחה האחרת, ולקוחות רבים מתקינים רק מסלולי IPv4. לכן מכונה עם קישוריות IPv6 מקורית יכולה להמשיך לדבר עם האינטרנט בזמן שצד IPv4 חסום היטב, ומתג החירום מדווח על הצלחה כל הזמן.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
השורה השלישית ראויה להבנה ולא לעקיפה. חומת אש מחליטה על חבילות, לא על איזה ממשק בקשה אפליקציה להשתמש, ותוכנית שנקשרת במפורש עלולה להיות קשה להכיל. זהו טיעון בעד מתג חירום בצד הלקוח שפועל מתחת לאפליקציה, ולא בעד עוד כללים.
בדקו על ידי עצירת הלקוח, לא על ידי משיכת הכבל
הבדיקה המשמעותית היחידה היא זו שמחקה את הכשל שאתם מגנים מפניו. עצרו את השירות, הרגו את התהליך או השביתו את המתאם שהלקוח יצר, ואז נסו להגיע לאינטרנט ולשם:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443שלושתם אמורים להיכשל. אם הראשון מצליח, החסימה אינה בתוקף; אם השני מצליח היכן שהראשון נכשל, יש לכם דליפת DNS; אם השלישי מצליח, IPv6 אינו מכוסה. כל תוצאה מצביעה בדיוק על אחד מהפערים שלמעלה.
חזרו על הבדיקה לאחר שינה והתעוררות, כי פרופיל חומת האש יכול להשתנות כשה-Windows מחליט שרשת היא ציבורית או פרטית, וכללים המוגבלים לפרופיל עוקבים אחריו. תכנון שמחזיק על שולחן ונכשל ברכבת הוא תכנון שנבדק פעם אחת.
אם שער הסיווג או דרישת ה-DNS הופכים את גישת חומת האש בלבד לבלתי מעשית, מתג חירום בצד הלקוח הוא התשובה הכנה. אם המנהרה מסתיימת בנתב במקום זאת, המדיניות צריכה להיות של הנתב, כי כלל אחד שם מכסה כל התקן שמאחוריו ואינו תלוי באופן שבו Windows מסמן מתאם.