RRAS DHCP: नयाँ ठेगाना कि केवल कन्फिगरेसन विकल्प?
VPN ट्रेसमा ACK ले जवाफ प्रमाणित गर्छ, बाँडफाँट होइन। ठेगाना RRAS को हुन सक्छ, जबकि DHCP ले जोडिएको क्लाइन्टलाई मात्र विकल्प पुर्याउँछ।
क्याप्चरमा रहेको DHCPACK लाई VPN क्लाइन्टले आफ्नो ठेगाना DHCP बाट पायो भन्ने प्रमाणका रूपमा पढ्नु गल्ती हो। सामान्यतया यसले कुनै DHCP सन्देशको जवाफ दिइयो भन्ने मात्र प्रमाणित गर्छ। Windows RRAS ले आफ्नै स्थिर पूलबाट सत्रका ठेगानाहरू दिन सक्छ, जबकि DHCP ले जोडिएको क्लाइन्टलाई विकल्प आपूर्ति गरिरहन्छ। कुन काम भइरहेको थियो भन्ने कुरा अनुरोधको प्रकारले बताउँछ।
एउटै सन्देश-प्रकार बाँड्ने दुई काम
DHCP ले दुई छुट्टै काम गर्छ, र ती सन्देश-प्रकार बाँड्छन्। एउटा ठेगाना र लिज बाँडफाँट गर्नु हो। अर्को पहिले नै ठेगाना भएको होस्टमा कन्फिगरेसन पुर्याउनु हो, जसलाई RFC 2131 ले DHCPINFORM भन्छ। दोस्रो अवस्थामा जवाफले विकल्प बोक्छ र कुनै लिज समय बोक्दैन।
त्यसैले ACK जवाफको प्रमाण हो, बाँडफाँटको प्रमाण होइन। कुन प्रश्न सोधियो भन्ने त्यसअघिको सन्देशले निर्धारण गर्छ। पहिले अनुरोध लाइन पढ्नुहोस्, बाँकी ट्रेस सामान्यतया आफैं स्पष्ट हुन्छ।
RRAS ले ठेगाना कहाँबाट पाउँछ
RRAS ले आफ्नो कन्फिगर गरिएको IPv4 बाँडफाँट विधिमार्फत VPN ठेगानाको निर्णय राख्छ: या त DHCP सर्भर वा स्थिर ठेगाना पूल। पूल स्थिर भएमा पूल नै बाँडफाँटकर्ता हो, र छुट्टै DHCP सर्भरमा गरिएको आरक्षणको त्यो सत्रमा केही भन्ने हुँदैन। दुवै संयन्त्र एउटै नेटवर्कमा एकले अर्कोलाई नियन्त्रण नगरी सहअस्तित्वमा रहन सक्छन्।
Get-Command -Module RemoteAccess *IPAddress*ठेगानाको समस्या हेर्नुअघि प्रचलित बाँडफाँट विधि पत्ता लगाउनुहोस्। यदि स्थिर पूल हो भने, DHCP स्कोप हेर्ने गलत ठाउँ हो। माथिको आदेशले तपाईंले चलाउनुभएको संस्करणमा उपलब्ध cmdlets सूचीबद्ध गर्छ, र सेटिङ भेट्न त्यति नै पर्याप्त छ।
प्रयोगकर्ता वर्गले के प्रमाणित गर्न सक्छ र के सक्दैन
DHCP प्रयोगकर्ता वर्ग भनेको क्लाइन्टले पठाउने स्ट्रिङ हो, प्रमाणित समूह सदस्यता होइन। क्लाइन्टले एउटा पठाए पनि र सर्भरले त्यसमा नीति मिलाए पनि, लेबलले स्ट्रिङ आइपुग्यो भन्ने मात्र प्रमाणित गर्छ। RFC 3004 ले यो विकल्पले वर्गमाथिको हक प्रमाणित गर्दैन भनी स्पष्ट भन्छ।
VPN प्रयोगकर्तानाम, सुरक्षा-समूह पहिचानकर्ता वा ल्यापटपको Ethernet ठेगाना त्यो अनुरोधमा प्रयोगयोग्य रूपमा देखिने अपेक्षा नगर्नुहोस्। यी प्रमाणीकरण र डाइरेक्टरीका तथ्य हुन्, र DHCP अनुरोधले दुवैमध्ये कुनै पनि बोक्दैन। आवश्यकता अधिकृत व्यक्तिहरू छुट्याउनु हो भने, पहिचान साँच्चै रहेको VPN नीतिमै लागू गर्नुहोस्। यही छुट्याइले दुई प्रणालीलाई स्वतन्त्र राख्छ।
ACK होइन, प्रमाणहरूको तुलना गर्नुहोस्
एउटा प्याकेट पढ्नुको सट्टा प्रमाणको साङ्लो बनाउनुहोस्। सत्रले पाएको ठेगाना, अनुरोधको सन्देश-प्रकार र फिल्डहरू, सर्भरले फर्काएका विकल्पहरू, र पछि क्लाइन्टको वास्तविक कन्फिगरेसन अभिलेख गर्नुहोस्। प्रत्येक कडीले फरक प्रश्नको जवाफ दिन्छ, र हराएको कडी नै वास्तविक खराबी सामान्यतया बस्ने ठाउँ हो।
Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0ठेगाना RRAS पूलबाट आएको भए, DHCP आरक्षणले केही पनि व्याख्या गर्दैन। विकल्पहरू आए तर क्लाइन्टले बेवास्ता गरे भने, सर्भरले आफ्नो काम गर्यो र अर्को स्टप क्लाइन्ट कन्फिगरेसन हो। यी दुई नतिजाको स्पष्ट तुलना गर्नुहोस्, ACK अस्पष्ट रहन छाड्छ। दुई ट्रेस, प्रत्येक बाँडफाँट विधिबाट एक, कुनै पनि कागजातभन्दा छिटो विवाद टुङ्ग्याउँछन्।