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 जैसा दिखे।
फिर लिखें कि मास्क का असल में क्या मतलब था, क्योंकि अगला व्यक्ति वही संवाद खोलेगा और वही ग़लत निष्कर्ष निकालेगा। प्रोफ़ाइल नोट्स में एक वाक्य, कि टनल पॉइंट-टू-पॉइंट है और दूर के सबनेट रूट के रूप में आते हैं, अगली बार पूरी जाँच बचा देता है।