VPN חוסם את ה-LAN המקומי ב-Windows: מסלול או מדיניות לקוח?
הגישה ל-LAN המקומי ב-Windows נשברת משתי סיבות שונות: מסלול חסר, או מדיניות שער שמפילה את תת-הרשת. שלוש בדיקות אומרות איזו.
מדפסת, NAS או מכונת פיתוח על השולחן שלכם מפסיקים להגיב ברגע שה-VPN של העבודה מתחבר. לפעמים פקודת מסלול מתקנת את זה בשניות; לפעמים אותו מסלול נכון והחבילות בכל זאת נעלמות, כלומר אתם רואים בעיה אחרת עם סימפטום דומה. ההחלטה מצטמצמת לשלוש שאלות, והצגתן בסדר הלא נכון היא הסיבה שאנשים מבלים ערב שלם במחיקה והוספה מחדש של מסלולים.
שלוש שאלות לפני כל פקודה
ראשית: האם קיימת רשומה עבור התחילית המקומית, והאם היא מצביעה על המתאם הפיזי? שנית: האם הלקוח מקבל מהשער הרשאה או סירוב לרשת המקומית בזמן החיבור? שלישית: האם אתם צריכים גישה יוצאת ל-LAN בלבד, או שמשהו באינטרנט צריך גם להגיע לשירות שרץ במחשב שלכם?
השאלה הראשונה מפרידה בין תקלת ניתוב לתקלת סינון. השנייה אומרת אם תיקון מסלול בכלל רשאי לפעול. השלישית משנה את התיקון: מסלול מתקן תעבורה יוצאת, בעוד שירות נכנס שאינו נגיש הוא בדרך כלל בעיית קישור מאזין ונתיב חזרה שמסלול מחמיר.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
שאלה ראשונה: מסלול, סינון או שם
קראו את הטבלה לפני שמוסיפים לה משהו. אינדקס הממשק חשוב, כי כל פקודת מסלול למטה מעוגנת בו:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricתת-רשת המחוברת ישירות שומרת בדרך כלל על מסלול על הקישור גם כשהמנהרה פעילה, כך שרשומה יכולה להתקיים והתעבורה בכל זאת להיכשל. השילוב הזה הוא החתימה של מסנן שרץ אחרי הניתוב, וזה המקרה שבו מסלול שני ומדויק יותר לא משנה דבר.
בדקו בנפרד לפי כתובת ולפי שם. אם ping 192.168.1.50 עונה ו-net view 192.168.1.50 לא, טבלת הניתוב מעולם לא הייתה הבעיה: המנהרה שינתה את הפותר והשם המקומי כבר לא נפתר. הוספת מסלול לשם כך היא עבודה מבוזבזת.
שאלה שנייה: האם השער מתיר גישה ל-LAN המקומי?
לקוח מסחרי מתקין יותר ממסלולים. הוא מקבל מדיניות בזמן החיבור, ומדיניות זו יכולה לכלול הרשאה מפורשת לרשת המקומית. בפריסות Cisco IPsec מדיניות הקבוצה נושאת את הגדרת split-tunneling ודגל נפרד לגישה ל-LAN המקומי; תיבת הסימון בלקוח היא בקשה שהשער רשאי לסרב לה. ב-AnyConnect הפרופיל שולט ברשימות ההכללה וההחרגה של split ובאותה הרשאה. ב-Windows RRAS המקבילות הן אפשרות שער ברירת המחדל בפרופיל ועוד המסלולים הסטטיים שהשרת מקצה.
כשהדגל כבוי, ההתנהגות המתועדת היא שהלקוח חוסם תעבורה לתת-הרשת המחוברת ישירות למרות שקיים מסלול תקף ומדויק יותר. זו גם הסיבה שמסלולים שהלקוח אינו הבעלים שלהם יכולים להיעלם שניות אחרי שהוספתם: הלקוח בונה מחדש את המצב שנאמר לו לבנות, ולא נלחם בכם.
יומן הלקוח רושם את ההחלטה בזמן החיבור, וקריאתו מהירה מכל ניסוי במחשב. אם היומן אומר שהגישה המקומית חסומה, עצרו: שום תיקון משורת הפקודה לא שורד את זה, והנתיבים היחידים שנותרו הם שינוי מדיניות, הגעה למשאב דרך המנהרה, או כליאת הלקוח במכונה וירטואלית והשארת המארח ברשת המקומית.
שאלה שלישית: איזה כיוון אתם צריכים?
תעבורה יוצאת אל התקן קרוב היא שאלת ניתוב. כוונו את תחילית ה-LAN אל השער המקומי עם מדד נמוך מספיק כדי לנצח את מסלול ברירת המחדל של המנהרה:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pהצורה השנייה מצמידה התקן יחיד, וזה מה שאתם רוצים כשכתובת אחת היא כל הדרישה. המקבילה של netsh רושמת את אותה החלטה לפי שם ממשק ולא לפי אינדקס:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentפקודות מסלול נכשלות עם הפרמטר שגוי כשהכתובת והמסכה אינן תואמות, למשל כתובת מארח עם מסכת /24. השתמשו בכתובת הרשת למסלול תת-רשת ובמסכת מארח למארח יחיד.
הנכנס שונה. שרת VNC או SSH באותו מחשב הופך לא נגיש כשהתשובות לחיבור נכנס יוצאות דרך שער ה-VPN ולעולם לא חוזרות. בדקו למה השירות מאזין לפני שנוגעים במסלולים:
netstat -ano | findstr :5900מאזין הקשור לכתובת אחת מסוימת לא יענה בממשק השני. קשירתו לכל הממשקים היא החלטה מכוונת, שנעשית יחד עם כלל חומת אש המוגבל לרשת שאתם סומכים עליה. רק אחרי זה תיקון המסלול מחזיר את נתיב החזרה.
החילו את השינוי הקטן שמתאים
המהלך הנפוץ האחר הוא לבטל את הסימון של "השתמש בשער ברירת מחדל ברשת המרוחקת" במאפיינים המתקדמים של IPv4. זה משאיר תעבורת אינטרנט מקומית, אבל עושה שני דברים בבת אחת: ה-VPN מפסיק להיות הנתיב הראשי, והלקוח מפסיק לקבל מסלולים לרשת המרוחקת, כולל multicast. בטלו אותו וה-LAN המרוחק נעלם אלא אם השרת דוחף את התחיליות המרוחקות המדויקות שכל לקוח צריך.
האסימטריה הזו קובעת את סדר העבודה. אם הצד המרוחק חייב להישאר נגיש לחלוטין, דחפו תתי-רשת מרוחקים מהשרת והניחו לברירת המחדל המקומית. אם אינכם יכולים לשנות את השרת, הוסיפו מסלול מתמיד לתחילית המרוחקת דרך הכתובת שהמנהרה הקצתה, ובדקו עם route print שהתחילית מצביעה על ממשק ה-VPN בעוד ברירת המחדל עדיין מצביעה על השער הפיזי.
לאחר מכן אשרו שהתיקון שורד חיבור מחדש, כי מסלולים לא מתמידים מתים עם המתאם וסקריפט שרץ אחרי כל חיבור הוא המקום הישר עבורם. בדקו התקן מקומי אחד ומשאב מרוחק אחד באותה הפעלה, נתקו, התחברו מחדש ובדקו שוב. אם ההתקן המקומי עדיין נכשל בעוד המסלול נראה נכון, חזרו לשאלה השנייה: הלקוח מסנן, והתשובה היא שינוי מדיניות ולא מסלול שני מתחרה.