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 இனி தெளிவற்றதாக இருக்காது. ஒவ்வொரு ஒதுக்கீட்டு முறையிலிருந்தும் ஒன்று என இரண்டு தடயங்கள், எந்த ஆவணத்தையும் விட விரைவாகத் தீர்க்கின்றன.