למה ה-VPN שלך ב-Windows הורג את המדפסת המקומית ואיך לעצור את זה

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

קרא תחילה את טבלת הנתיבים

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

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

הסר את נתיב ברירת המחדל, בשלוש דרכים

בפרופיל Windows מובנה הבקרה היא תיבת סימון. פתח את מאפייני החיבור, IPv4, ואז מתקדם, ונקה Use default gateway on remote network; אפליקציית ההגדרות החדשה יותר מסתירה את אותה תיבה עוד שכבה אחת פנימה. משורת פקודה מוגברת אותו שינוי הוא cmdlet אחד:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

OpenVPN-פרופיל עובד אחרת, ולכן ההתנהגות שלו מבלבלת מי שמצפה לתיבת סימון. הוראת redirect-gateway def1 שלו כלל אינה מחליפה את נתיב ברירת המחדל; היא מתקינה שני נתיבים של חצי טווח, 0.0.0.0/1 ו 128.0.0.0/1, אשר יחד מנצחים את ברירת המחדל בלי למחוק אותה. מכיוון שברירת המחדל המקורית שורדת, הוספת קידומת שמצביעה אל net_gateway מחזירה רק את הקידומת הזו אל הנתב המקומי. הפרט הזה מסביר למה התיקון לפרופיל def1 הוא נתיב קידומת ולא תיבת סימון שאיש לא מוצא.

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

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

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

הגישה הישנה יותר עדיין עובדת ועדיין נמצאת בכל רשימת בדיקה: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, עם אינדקס הממשק וכתובת השער של המנהרה עצמה. הוא נשמר בין אתחולים, וזו הכוונה וגם הסכנה, כי האינדקס עלול להשתייך למשהו אחר באתחול הבא.

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

כשהשרת מחליט בשבילך

לקוח שמתעלם מתיבת הסימון שלך בדרך כלל מציית למדיניות. פרופילי Cisco נושאים הגדרה Allow Local LAN Access, ו-headend יכול לדחוף מדיניות tunnel-all שמבטלת את מה שהלקוח היה מעדיף; בפריסה של מנהרה כפויה אין מתג מקומי להפוך. קרא את יומן הלקוח לנתיבים ולשורות מדיניות שנדחפו במקום לבדוק שוב את אותה תיבה.

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

חפיפות הן בעיה אחרת

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

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