הרשת המקומית לא נגישה כשה-VPN מחובר? ארבע בדיקות

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

ראשית, הביטו בטבלת הניתוב שהלקוח התקין

פתחו את טבלת הניתוב של הלקוח בזמן שה-VPN מחובר. ב-Linux השתמשו ב-ip route, ב-Windows ב-route print או ב-Get-NetRoute, וב-macOS ב-netstat -rn. אתם מחפשים מסלול ברירת מחדל דרך המנהרה ומה קרה למסלול ברירת המחדל הפיזי.

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

אם המנהרה חייבת להישאר מסלול ברירת המחדל, הצמידו במקום זאת את תת-הרשת המקומית. ב-Linux המסלול מציין את הממשק הפיזי ואת השער; ב-Windows הוסיפו -p כדי שיהיה קבוע וקראו את מספר הממשק מתוך route print במקום לנחש אותו:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

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

שנית, ודאו שהכתובת הייתה מקומית מלכתחילה

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

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

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

שלישית, ראו מי עונה לשמות כעת

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

ב-Linux, resolvectl query nas.local מראה איזה פותר ענה. ב-Windows, nslookup nas.local מציין את השרת, ו-ipconfig /all מראה את סדר הפותרים. אם הסיומת המקומית מטופלת כעת על ידי הפותר הארגוני, או שהעבירו את הסיומת חזרה לפותר המקומי או השתמשו בכתובת ה-IP של ההתקן.

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

רביעית, בדקו אם גם המחשב האחר נמצא ב-VPN

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

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

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

החילו את התיקון שמתאים לבדיקה שנכשלה

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

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

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