למה טבלת הניתוב של VPN ב-Windows מציגה 0.0.0.0/1 ו-128.0.0.0/1

התחברו ל-VPN של Windows ופתחו את טבלת הניתוב, ושתי רשומות בולטות: 0.0.0.0/1 ו-128.0.0.0/1. הן אינן שגיאת הקלדה והן אינן מחליפות את ברירת המחדל. הופעתן תלויה באפשרות פרופיל אחת, והזוג הוא הדרך שבה נבנה מנהרה מלאה, לא תכונה של מנהרה מפוצלת. קראו את האפשרות, הקידומת והממשק יחד לפני שתשנו שורה אחת.

מה מתקינה אפשרות שער ברירת המחדל

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

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

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

פירוק זול יותר משמירת שער

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

לקוחות אחרים מגיעים לאותה תכנון. פרופיל OpenVPN עם redirect-gateway def1 מתקין את שתי הקידומות האלה במקום למחוק את ברירת המחדל, ולקוח Windows הולך באותו דפוס מאותה סיבת ניתוב.

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

הקידומת הארוכה ביותר מנצחת לפני כל מדד

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

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

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

בחרו בעלים אחד לקידומת המשרד

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

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

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

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

אמתו עם יעד, לא עם אתר אינטרנט

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

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

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

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