כיצד להסיר נתיב ישן שהותיר VPN של Windows

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

1. החליטו אם הרשומה מיושנת או מכוונת

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

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

2. רשמו את ארבעת השדות שמזהים את הרשומה

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

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

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

3. הציגו תצוגה מקדימה של ההסרה, ואז הסירו רשומה אחת

Remove-NetRoute מקבל את אותה קידומת ואותו אינדקס ממשק ש-Get-NetRoute הדפיס, ויש לו מתג תצוגה מקדימה, כך שאין צורך לנחש דבר. הריצו את הצמד בסדר הזה:

Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42

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

4. מצאו איזה רכיב מחזיר אותה

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

Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore

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

5. אמתו את החיפוש, השכנים וההערה

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

Find-NetRoute -RemoteIPAddress 10.20.4.7

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