אין אינטרנט ב-VPN של Windows? מאגר הכתובות הוא החשוד
מנהרה מחוברת בלי אינטרנט בדרך כלל אין לה שער שמיש. קראו מה קיבל הלקוח, הגדירו מאגר מפורש, ואז תנו למנהרה מוצא.
Windows מציג את המנהרה כמחוברת ומסמן אותה בתווית אין גישה לאינטרנט, שאנשים קוראים כמוזרות של Windows. זהו הצהרה על מה שהלקוח קיבל: אין שער ברירת מחדל שמיש, אין פותר עובד, או אין נתיב חזרה לכתובות שבתוך המנהרה. כשהשרת הוא Incoming Connection של Windows, הגדרה אחת מסבירה את רוב הדיווחים כאלה. התווית אינה אבחנה, אבל היא מצמצמת את החיפוש לשלושה מקומות.
קראו את החכירה לפני שמשנים אותה
הריצו ipconfig /all בלקוח ומצאו את מתאם ה-VPN בין הרשומות. הכתובת, שער ברירת המחדל ושרת ה-DNS שהוא מפרט הם העובדות שדרושות לכם, ולעיתים קרובות הם שונים ממה שהמנהל מניח שהוקצה.
שלושה דפוסים מתאימים לשלוש תקלות. כתובת ב-169.254.0.0/16 פירושה שהלקוח לא קיבל דבר והקצה לעצמו כתובת קישור-מקומית. כתובת סבירה בלי שער פירושה שהמאגר הוגש בלי האפשרות שנותנת ללקוח נתיב ברירת מחדל. חכירה מלאה שעדיין לא מגיעה לשום מקום מצביעה על העברה או תרגום בצד השרת.
רשמו את הערכים לפני שנוגעים בשרת. השלב הבא משווה אותם לטווח שהשרת חושב שהוא מחלק, והזיכרון הוא תחליף גרוע לחכירה.
למה הקצאה אוטומטית עלולה להשאיר בלי שער
לרשומת Incoming Connections יש מאפייני IPv4 משלה, בנפרד מהמתאם הפיזי. ברירת המחדל שם מציעה להקצות כתובות אוטומטית, מה שנשען על מקצה מובנה של החיבור כדי לספק כתובת, מסכה, שער ו-DNS.
בתחנת עבודה עצמאית אין למקצה הזה טווח שממנו למשוך, אלא אם משהו אחר במכונה מספק אחד, כך שהלקוח עלול להיגמר עם כתובת קישור-מקומית או עם כתובת אך בלי שער. החיבור נראה כמבוסס משום שהקישור עלה, בעוד שהתצורה שמאחוריו אינה שלמה.
זו הסיבה שמעבר לטווח מוגדר מתקן כל כך הרבה מהדיווחים האלה. מפסיקים לבקש משירות שאולי אינו פועל להמציא חכירה ומתחילים להצהיר על החכירה בעצמכם.
אותה מבוכה מופיעה כשמישהו מצפה ששרת ה-DHCP של ראוטר ה-LAN ישרת לקוחות מנהרה. גילוי שידור אינו חוצה מנהרה מנותבת, כך שהשרת הזה לעולם אינו רואה את הבקשה. להניח אחרת זו הסיבה הנפוצה ביותר להאשים מאגר בלקוח שמעולם לא ביקש ממנו דבר.
הגדירו טווח מפורש שהשרת יכול לנתב
בחרו גוש קטן בתוך תת-רשת שהשרת יכול להגיע אליה, מחוץ לטווח שראוטר ה-LAN מחלק, ומחוץ לכל מאגר אחר ברשת. אם השרת יושב על 172.20.10.0/24 והראוטר מחזיק את 172.20.10.1, גוש קצר סמוך לראש תת-הרשת, נניח 172.20.10.201 עד 172.20.10.209, משאיר את חכירות המנהרה מחוץ לחלוקה שהראוטר כבר מנהל.
הזינו אותו במאפייני IPv4 של ה-Incoming Connection, חברו מחדש את הלקוח, וקראו שוב את המתאם לפני שמשנים משהו אחר. קריאה שנייה היא מה שאומר לכם אם המאגר היה התקלה או רק תקלה אחת מכמה.
הפקודות האלה מדפיסות את התצורה הנובעת ואת הנתיבים שיש ללקוח כעת:
ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"השער בחכירה צריך להיות כתובת שהשרת מחזיק, ונתיב ברירת המחדל של הלקוח צריך להצביע אליה. אם החכירה שלמה אך אין נתיב, השרת הקצה בלי לדחוף שער, והגדרות המאגר עדיין המקום לחפש בו.
כתובת אינה נתיב לאינטרנט
קבלת חכירה רק מעבירה מנות מהלקוח לשרת. לגישה לאינטרנט השרת חייב להעביר את המנות האלה ולתרגם אותן לעבר הקו העולה שלו, וזו תצורה נפרדת עם אופני כשל משלה.
Internet Connection Sharing הוא הקיצור. הוא הופך את המתאם הפונה לאינטרנט לשער משותף ומריץ כתובות משלו, מה שעלול לשכתב את כתובת המתאם הזה ולהשאיר כלל NAT קיים שמצביע לערך שכבר אינו קיים. רשמו את ההגדרות המקוריות לפני שמפעילים אותו.
החלופה המנותבת משאירה את הכתובות יציבות ומבקשת מכם להגדיר העברה ותרגום במפורש. אף אחת מהגישות אינה שגויה; ערבוב שלהן עד חצי דרך מייצר מנהרה עם חכירה ובלי מוצא, וזה בדיוק הסימפטום שאיתו התחלתם. בחרו מודל אחד והשלימו אותו לפני שמוסיפים את האחר.
פסלו קודם את הנתיב החיצוני
שום מאגר לא יעזור אם המנהרה לא נוצרת. הפרוטוקול קובע מה הנתיב חייב לשאת: PPTP רוצה TCP 1723 ו-GRE, שהוא פרוטוקול IP 47 ולא פורט; L2TP/IPsec רוצה UDP 1701 ועוד 500 ו-4500; SSTP רוצה TCP 443.
ראוטר שמעביר את הפורט אך לא את הפרוטוקול מייצר ניסיון חיבור שלעולם אינו מאמת. זהו כשל שונה ממנהרה שנוצרת ואז לא מגיעה לשום מקום, ואת השניים אין לבדוק יחד.
בדקו מאותה LAN ומהרשת המרוחקת. אם הניסיון ב-LAN עובד והמרוחק לא מגיע לאימות, הנתיב החיצוני הוא הבעיה. אם שניהם מאמתים ורק הלקוח המרוחק בלי אינטרנט, חזרו למאגר ולמוצא.