איך לבדוק מה VPN ב-Windows באמת מנתב ב-PowerShell
אריח VPN מחובר אינו מוכיח כיסוי. קראו את דגל הפרופיל השמור, את טבלת הניתוב החיה ואת כללי NRPT בסדר הזה.
חיברתי את לקוח ה-VPN במחשב נייד עם Windows 11, האריח עבר ל-Connected, שיתוף קבצים פנימי נפתח, ואתר ציבורי עדיין נטען ישירות מה-Wi-Fi של המשרד. התערובת הזאת נראית כמו מנהרה שבורה. זה הפלט הרגיל של פרופיל ששולח חלק מהתעבורה דרך ה-VPN ומשאיר את השאר על המתאם הפיזי. ניתוב כפוי משנה איזה נתיב ברירת מחדל Windows מעדיף; הוא לא מוחק נתיבים ספציפיים יותר ולא מבטיח שהתעבורה תיעצר כשהחיבור נופל. להלן הסדר שבו אני עובר כשלקוח טוען לכיסוי: מצב הלקוח, פרופיל שמור, נתיבים מיושמים, פותר שמות, ואז זרימות אמיתיות.
התחילו בלקוח, ואז הפסיקו לסמוך עליו
הלקוח הוא נקודת ההתחלה הנכונה רק מפני שהוא אומר לכם איזה פרופיל פעיל. פתחו את מאפייני החיבור ורשמו את שם הפרופיל המדויק, אם הוא נוצר עבור המשתמש הנוכחי או עבור כולם במחשב, ואיזה מתאם מופיע בתוך ncpa.cpl לאחר החיבור. במחשב הנייד לבדיקות שלי המתאם נשא את שם הפרופיל, מה שהקל לקרוא את פלט הנתיבים. במחשבים אחרים הוא מופיע כרשומת WAN Miniport והשם לא אומר לכם דבר.
מה שהלקוח לא יכול לומר לכם הוא הכיסוי. אריח מחובר מתאר את מצב המנהרה, לא מלאי של יעדים. גם לקוחות של צד שלישי שומרים על תצורה משלהם, ולכן ייתכן שפרופיל Windows המקורי, וכל מאפיין שתקראו ממנו, לא קשורים למה שאותו לקוח התקין. אם ה-VPN הגיע דרך AnyConnect, OpenVPN GUI, WireGuard או סוכן של ספק, בדיקות ה-PowerShell שלהלן בדרך כלל לא חלות וכדאי לקרוא את הגדרות ה-split-tunnel והניתוב של אותו לקוח.
קראו את הפרופיל השמור, לא את האריח
עבור פרופיל Windows מקורי (IKEv2, L2TP, SSTP או כזה שנדחף על ידי MDM) החלטת ה-split-tunnel השמורה היא מאפיין אחד:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixהוסיפו -AllUserConnection כשהפרופיל נוצר עבור כולם במכשיר. בלעדיו אתם קוראים את הרשימה של המשתמש הנוכחי, שעשויה להיות ריקה או להחזיק רשומה אחרת בשם דומה. ערך False בתוך SplitTunneling פירושו שהפרופיל נשמר כמנהרה מלאה: Windows מתקין נתיב ברירת מחדל דרך מתאם ה-VPN. True פירושו split tunnel, והכיסוי תלוי אז כולו בנתיבים ובכללי פתרון השמות שהפרופיל דוחף.
התייחסו לערך הזה כתצורה, לא כתצפית. הוא מתעד מה הפרופיל ביקש בזמן החיבור. Windows עשוי לסיים עם נתיבים מיושמים שונים, בגלל נתיב ספציפי יותר של ממשק אחר, הגדרת מדיניות או רשומה שנותרה מחיבור קודם, ולכן הערך הבוליאני לא מכריע את השאלה לבדו.
השוו את הערך השמור לטבלת הנתיבים המיושמת
לאחר החיבור, פרטו את הנתיבים במתאם המנהרה במקום לגלול את כל הטבלה:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute הוא החצי השימושי. הוא עונה לשאלה שהלקוח אף פעם לא עונה עליה: עבור היעד הזה, באיזה ממשק ובאיזו כתובת מקור Windows ישתמש בפועל? הריצו אותו עבור מארח פנימי, מארח ציבורי וכל דבר שאתם חושבים שהוא חריגה מכוונת. פרופיל מנהרה מלאה אמור להראות את ממשק המנהרה עבור הכתובת הציבורית. פרופיל split tunnel מראה שם בדרך כלל את המתאם הפיזי בעוד קידומות פנימיות עדיין נפתרות ל-VPN.
שתי מלכודות מסבירות את רוב הדיווחים «הוא מנתב לא נכון». הקידומת הספציפית ביותר תמיד מנצחת, ולכן /24 על המתאם הפיזי מנצח נתיב ברירת מחדל ב-VPN לא משנה כמה נמוכה המדדה של המנהרה. המדדה מכריעה רק שוויון בין נתיבים לאותה קידומת. ו-IPv4 ו-IPv6 מוכרעים בנפרד: פרופיל שמכסה 0.0.0.0/0 יכול להשאיר את IPv6 על הקישור המקומי, מה שגורם לאתר דו-סטאק להיראות חצי מנוהר. בדקו את Get-NetRoute -AddressFamily IPv6 לפני שאתם מסיקים שהמנהרה תקינה.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
בדקו פתרון שמות בנפרד עם NRPT
שמות פנימיים שנכשלים בזמן שכתובות IP פנימיות עובדות מצביעים על מדיניות פותר השמות, לא על ניתוב. Windows מכריע DNS לכל מרחב שמות דרך טבלת מדיניות פתרון השמות, שאינה תלויה בטבלת הנתיבים:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexכשכלל מתאים ל-*.corp.example, שאילתות עבור מרחב השמות הזה הולכות לשרתי ה-DNS של המנהרה גם אם נתיב הנתונים לשרתים האלה נשאר על המתאם הפיזי במצב split tunnel. זה התכנון, ולכן בדיקת דפדפן שפותחת אתר ציבורי לא אומרת לכם דבר על שמות פנימיים. אם המתאם מפרט את השרתים הצפויים אבל החיפושים עדיין הולכים למקום אחר, השוו את סדר כללי NRPT ובדקו אם מרחב שמות ספציפי יותר מתאים ראשון.
אמתו את הזרימות, ואז החליטו מה באמת ביקשתם
עברו על היעדים בסדר קבוע כדי שהתוצאות יהיו ניתנות להשוואה בין מחשבים: כתובת ציבורית, כתובת פנימית, שם פנימי וחריגה מכוונת אחת כמו מדפסת מקומית או שיחת וידאו. רשמו את הממשק ואת כתובת המקור ש-Find-NetRoute מחזיר לכל אחד. לאחר כל שינוי מדיניות, התחברו מחדש וחזרו על אותן ארבע בדיקות; טבלת הנתיבים שאחרי ההתחברות מחדש היא הראיה היחידה שהפרופיל החדש נכנס לתוקף.
ואז הפרידו בין ניתוב לאכיפה. ניתוב כפוי מעדיף את המנהרה עבור תעבורה מכוסה כל עוד היא פעילה. הוא לא מתג הרג. אם הדרישה היא ששום דבר לא יצא מהמחשב כשהמנהרה נופלת, זה חייב לבוא מתכנון חוסם: פרופיל חומת אש הקשור למצב המנהרה, פרופיל תמיד-פעיל עם מסנני תעבורה או אפשרות הסגירה-בכשל של לקוח הספק. ניתוב כפוי גם חייב להשאיר את הכתובת של שרת ה-VPN עצמו נגישה מחוץ למנהרה, וחסימתה בשם «לכפות הכול» היא דרך אמינה לנעול את עצמכם מחוץ לחיבור שאתם מנסים לאכוף.
לפני שאתם משנים משהו, עברו על הרשימה הזו. כל פריט שנכשל מצמצם היכן הבעיה האמיתית.
- שם הפרופיל וההיקף אושרו, עם
-AllUserConnectionלפרופילים ברמת המחשב. SplitTunnelingנקרא ויוחס כתצורה ולא כהוכחה לכיסוי.- נתיבי מתאם המנהרה פורטו בנפרד עבור IPv4 ו-IPv6.
Find-NetRouteהורץ עבור יעד ציבורי אחד, פנימי אחד ויעד חריגה אחד.- כללי NRPT נבדקו לפני האשמת הנתיבים בכשל של שם.
- דרישת החסימה נקראה שוב: ניתוב מועדף אינו זהה לחסימה נאכפת.
ההחלטה על מנהרה מלאה או split שייכת למי שבבעלותו הפרופיל, והערות הניתוב של Microsoft מתארות את ההתנהגות ש-Windows מיישם כשפרופיל מגדיר אותה. Microsoft: מנהרה כפויה ו-split הוא המקור שאני משאיר פתוח בזמן קריאת הפלט.