לקוחות VPN נחסמים על ידי פרופיל חומת האש הציבורי של Windows

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

זהה באיזה פרופיל התעבורה באמת מגיעה

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

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

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

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

אמת שזה סינון ולא ניתוב לפני עריכת כללים

Ping היא בדיקה חלשה. ייתכן ש-ICMP עובר בזמן שפורט השירות נזרק, והמארח עשוי להשיב מה-LAN בזמן שהוא דוחה את אותה בקשה דרך המנהרה. בדוק את הפורט שהלקוח צריך, מהלקוח:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

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

כשהתוצאה עדיין לא חד-משמעית, רשום את ההשלכות עבור הפרופיל הרלוונטי וקרא אותן:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

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

הגבל כלל נכנס אחד למאגר הלקוחות

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

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

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

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

רשום את המאגר לצד הכלל. -RemoteAddress 10.8.0.0/24 מפסיק בשקט להתאים ביום שבו מאגר ה-VPN ממוספר מחדש, והתקלה נראית בדיוק כמו הבאג המקורי, ולכן היא עולה עוד אחר צהריים. תן לכללים שמות לפי השירות וטווח המקור, שמור אותם יחד עם -Group, וקרא אותם מחדש בכל שינוי של הגדרת המאגר. מלאי כללים שאפשר לבקר במסך אחד עדיף על כלל נכון שאף אחד לא מוצא.

שנה קטגוריה רק כשהקטגוריה היא ההחלטה

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

במכשיר מנוהל, בדוק תחילה אם מדיניות קבוצה או קו בסיס של MDM מחזיק בהגדרה. אם כן, השינוי המקומי יוחזר ברענון הבא, ו- gpresult /h יציין את המדיניות שמחזיקה בה; תקן שם, לא בנקודת הקצה.

אמת משני הקצוות והשאר עקבה

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

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

לפני שאתה מכריז שסיימת:

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