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