VPN ב-Windows מציג 255.255.255.255: האם המסכה שגויה?
במנהרת נקודה לנקודה מסכת מארח היא נורמלית. אשרו את מודל הממשק, קראו את המסלול למארח שנכשל והפרידו בין DNS לגישה לשירות.
המנהרה מתחברת, אתם פותחים את פרטי המתאם והמסכה מציגה 255.255.255.255. בהשוואה ל-255.255.255.0 של רשת המשרד זה נראה שבור, ושם בדרך כלל מתחילה השגיאה. בקישור נקודה לנקודה מסכת מארח היא התיאור הנכון של הקצה המקומי, והרשתות המרוחקות מגיעות כמסלולים ולא כתת-רשת מחוברת. הנוהל שלהלן מפריד בין שתי השאלות כדי שלא תבנו מחדש טווח DHCP עובד רק כדי לתקן ערך מוצג.
קישור נקודה לנקודה אינו מקטע Ethernet
ממשק Ethernet זקוק למסכת תת-רשת משום שכל כתובת בטווח הזה עשויה להיות נגישה באותו כבל. למנהרה בסגנון PPP יש בדיוק עמית אחד בקצה השני. אין תחום שידור, אין ARP ואין סיבה שהכתובת המקומית תתאר טווח.
משא ומתן הכתובות למודל הזה מוגדר ב-RFC 1332, שמתאר כיצד שני הקצוות מסכימים על הכתובות שלהם. מה שהוא לא עושה הוא לתת ללקוח את רשת המשרד כרשת מחוברת ישירות. הלקוח לומד היכן המשרד על ידי התקנת מסלולים דרך הקישור, והמסלולים האלה הם שקובעים בפועל את הנגישות.
זה לא אומר שכל מסכה שתראו נכונה. לקוח שהוגדר שגוי יכול גם לייצר כתובות מוזרות. הנקודה צרה יותר: מסכת מארח במתאם מסוג זה היא צפויה, ולכן כשלעצמה אינה הוכחה לתקלה.
שלב 1: אשרו את מודל הממשק
בדקו מהו המתאם לפני שתשפטו מה הוא אומר. מחרוזת התיאור מזהה את מנהל ההתקן, ואורך הקידומת בכתובת שהוקצתה מאשר למה הלקוח התחייב:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu
הפקודה השלישית היא זו שמכריעה את רוב הוויכוחים. יחידת שידור מרבית נמוכה אופיינית לקישור עטוף, ואילו ערך דמוי Ethernet מרמז על מודל מתאם וירטואלי אחר. אם התיאור מציין מנהל התקן PPP או RAS והקידומת היא 32, אתם רואים בדיוק את העיצוב שתואר לעיל ויכולים להפסיק לדאוג מהמסכה.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
שלב 2: קראו את המסלול ליעד שנכשל
הנגישות נקבעת לכל יעד, וממשק מחובר אחד לא אומר לכם דבר על כך. שאלו את טבלת המסלולים ישירות על הכתובת שהמשתמש באמת מנסה להגיע אליה:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4
Find-NetRoute היא התשובה הישירה: היא מציינת את הממשק ואת כתובת המקור שהמערכת תשתמש בה ליעד הזה. אם היא מחזירה את המנהרה, התעבורה למארח הזה עוברת במנהרה והמסכה מעולם לא הייתה הבעיה.
אם היא מחזירה את המתאם הפיזי, השוו בין שני המסלולים האפשריים לבין המדדים שלהם. מסלול מקומי ספציפי יותר, רשומה שנותרה מלקוח אחר או מדד נמוך יותר בנתיב הפיזי גוברים כולם על מסלול מנהרה רחב. התוצאה הנראית היא משאב שאינו נגיש בזמן שכל השאר עובד. קידומות ארוכות יותר תמיד מנצחות, ולכן המנצח הוא לעתים קרובות מסלול מארח שמישהו הוסיף לפני חודשים ושכח.
בדקו כאן גם את שני הכיוונים. מסלול לצד השרת הכרחי אך אינו מספיק, משום שגם התשובה חייבת לחזור דרך המנהרה. כשמארח פנימי אחד עובד ואחר לא, ההבדל נמצא בדרך כלל בטבלה הזו ולא בתצורת המתאם.
שלב 3: הפרידו בין פתרון שמות לגישה לשירות
יישום שלא פותח שיתוף יכול להיכשל באחד משני שלבים שונים מאוד. פתרו את השם ואז הגיעו לכתובת. אם הראשון נכשל והשני עובד, המנהרה תקינה והפותרן לא:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445
בדיקת כתובת מוצלחת יחד עם בדיקת שם כושלת ממקמת את הבעיה בפתרון השמות, והפקודה השנייה מראה אם ממשק המנהרה קיבל שרת בכלל. לקוחות רבים דוחפים DNS כחלק מתצורת המנהרה, ופרופיל שמתעלם מהאפשרויות הנדחפות האלה ישאיר את המחשב עם פותר שאינו רואה את האזור הפרטי.
אל תתייחסו לכתובת עובדת כתיקון קבוע. התחברות לפי כתובת עוקפת את פתרון השמות ועלולה להחליש את אימות זהות השרת שהיישום היה מבצע אחרת. זו נסיגת אבטחה בתחפושת של פתרון זמני. השתמשו בה כדי למקם את התקלה ואז תקנו את הפתרון.
חזרה לאחור: אל תבנו מחדש DHCP בגלל ערך מוצג
אם כבר התחלתם לשנות את שירות הכתובות, עצרו ובדקו אם משהו ממה ששיניתם נושא עומס. יצירה מחדש של טווח, הוצאה מחדש של חכירות או העברת המאגר משנה מצב שלקוחות אחרים תלויים בו, ושום דבר מזה אינו מוצדק על ידי מסכת מארח במתאם נקודה לנקודה.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445
הריצו את שלוש הפקודות אחרי כל שינוי ממוקד והשוו להרצה הקודמת. התוצאה השימושית היא נתיב מתועד למשאב, לא מתאם שהמסכה שלו דומה לרשת המשרד.
ואז כתבו מה המסכה באמת הייתה, כי האדם הבא יפתח את אותו דו-שיח ויגיע לאותה מסקנה שגויה. משפט אחד בהערות הפרופיל, שהמנהרה היא נקודה לנקודה ותת-הרשתות המרוחקות מגיעות כמסלולים, חוסך את כל החקירה בפעם הבאה.