Windows चा VPN 255.255.255.255 दाखवतो: मास्क चुकीचा आहे का?
पॉइंट-टू-पॉइंट टनेलमध्ये होस्ट मास्क सामान्य आहे. इंटरफेसचे मॉडेल तपासा, अयशस्वी होस्टचा रूट वाचा आणि DNS सेवा प्रवेशापासून वेगळे करा.
टनेल जोडली जाते, तुम्ही अडॅप्टरचे तपशील उघडता आणि मास्क 255.255.255.255 दाखवतो. कार्यालयातील LAN च्या 255.255.255.0 शी तुलना करता तो तुटलेला दिसतो, आणि चूक सहसा तिथूनच सुरू होते. पॉइंट-टू-पॉइंट लिंकवर होस्ट मास्क स्थानिक टोकाचे योग्य वर्णन आहे, आणि दूरची नेटवर्के जोडलेल्या सबनेटऐवजी रूट म्हणून येतात. खालील प्रक्रिया दोन्ही प्रश्न वेगळे करते जेणेकरून फक्त दाखवलेले मूल्य दुरुस्त करण्यासाठी चालू DHCP स्कोप पुन्हा बांधू नका.
पॉइंट-टू-पॉइंट लिंक Ethernet विभाग नाही
Ethernet इंटरफेसला सबनेट मास्क लागतो कारण त्या श्रेणीतील प्रत्येक पत्ता त्याच केबलवर संभाव्यतः पोहोचण्यायोग्य असतो. PPP शैलीतील टनेलच्या दुसऱ्या टोकाला नेमका एक सहकारी असतो. येथे ब्रॉडकास्ट डोमेन नाही, ARP नाही आणि स्थानिक पत्त्याने श्रेणीचे वर्णन करण्याचे कारण नाही.
त्या मॉडेलसाठी पत्ता वाटाघाटी RFC 1332 मध्ये परिभाषित आहे, जी दोन्ही टोके आपल्या पत्त्यांवर कशी सहमत होतात हे सांगते. ती जे करत नाही ते म्हणजे क्लायंटला कार्यालयाचे LAN थेट जोडलेले नेटवर्क म्हणून देणे. क्लायंट कार्यालय कुठे आहे हे लिंकमधून रूट बसवून शिकतो, आणि तेच रूट प्रत्यक्षात पोहोच ठरवतात.
याचा अर्थ तुम्हाला दिसणारा प्रत्येक मास्क बरोबर आहे असा नाही. चुकीच्या संरचनेचा क्लायंटही विचित्र पत्ते तयार करू शकतो. मुद्दा अरुंद आहे: या प्रकारच्या अडॅप्टरवर होस्ट मास्क अपेक्षित आहे, म्हणून तो स्वतःच बिघाडाचा पुरावा नाही.
टप्पा 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 -4Find-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ही तीन कोणत्याही लक्ष्यित बदलानंतर चालवा आणि मागील फेरीशी तुलना करा. उपयुक्त निकाल संसाधनापर्यंतचा दस्तऐवजीकृत मार्ग आहे, असा अडॅप्टर नाही ज्याचा मास्क कार्यालयाच्या LAN सारखा दिसेल.
मग मास्कचा खरोखर अर्थ काय होता ते लिहा, कारण पुढची व्यक्ती तोच संवाद उघडेल आणि तोच चुकीचा निष्कर्ष काढेल. प्रोफाइल नोंदींमधील एक वाक्य, की टनेल पॉइंट-टू-पॉइंट आहे आणि दूरची सबनेट रूट म्हणून येतात, पुढच्या वेळी संपूर्ण तपासणी वाचवते.