RRAS VPN வாடிக்கையாளர்களுக்கு சொந்த IPv4 குளம் மற்றும் திரும்பும் பாதை தேவை

VPN வாடிக்கையாளர் இணைந்து ஒரு முகவரியைப் பெறுகிறார், ஆனால் அவருக்குத் தேவையான LAN புரவலர் இன்னும் பதிலளிக்க முடியவில்லை. Windows Routing and Remote Access இல் VPN வாடிக்கையாளர்களின் உள் முகவரி சேவையகத்தின் LAN அடாப்டரிலிருந்து தனியாக அமைக்கப்பட்ட குளத்திலிருந்து வருகிறது, மேலும் LAN பக்கத்திற்கு அந்தக் குளத்திற்குத் திரும்பும் பாதை தேவை. இரண்டு மாற்றங்கள், ஒன்றல்ல, அவை வெவ்வேறு வழிகளில் தோல்வியடைகின்றன. பழைய வரம்புகள் நீக்கப்படும் முன் முகவரித் திட்டமும் திரும்பும் பாதையும் நிரூபிக்கப்படும் வகையில் அவற்றை வரிசையாகச் செய்யுங்கள்.

கன்சோலைத் திறக்கும் முன் வரம்பை ஒதுக்குங்கள்

LAN, மற்ற VPN வரம்புகள் அல்லது தளத்திற்கு வழிமாற்றப்படும் எதனுடனும் ஒன்றுடன் ஒன்று கலக்காத முன்னொட்டைத் தேர்ந்தெடுங்கள். சோதனைக்கு /24 வசதியான அளவு, முதல் பயன்படுத்தக்கூடிய பகுதியை வாடிக்கையாளர்களுக்கு வழங்கலாம், மீதமுள்ளது வளர்ச்சிக்கு இலவசமாக இருக்கும். கன்சோலில் தட்டச்சு செய்வதற்கு முன் அதை அதன் நோக்கம் மற்றும் உரிமையாளருடன் எழுதி வையுங்கள். பின்னர் நடக்கும் பிரிப்பு மறுஎண்ணிடலை கட்டாயப்படுத்தாதபடி தொகுதியின் இரு முனைகளிலும் இடம் விடுங்கள்.

கன்சோலில் மட்டுமே வாழும் முகவரித் திட்டம் ஒரு மறுகட்டுமான தூரத்தில் மோதலில் இருக்கும். அது வளரும் போக்கையும் கொண்டுள்ளது: யாரோ பின்னர் இரண்டாவது வரம்பைச் சேர்ப்பார், முதல் வரம்பை யாரும் சரிபார்க்க மாட்டார். திட்டத்தை அரட்டை இழையில் அல்ல, சேவையக ஆவணங்களுக்கு அருகில் வைத்திருங்கள்.

சேவையகத்தின் LAN அடாப்டர் இந்தக் குளத்தை வரையறுக்கவில்லை. பொது ஊடகத்தை மாற்றுவது அல்லது LAN இல் அடாப்டரைச் சேர்ப்பது முற்றிலும் வேறு ஒன்றைச் செய்கிறது. அதனால்தான் வாடிக்கையாளர்கள் இணைந்தும் தவறான இடத்திலிருந்து முகவரியைப் பெறலாம். குளம் சேவையகத்தின் IPv4 பண்புகளில் வாழ்கிறது, அடாப்டர் பட்டியலில் அல்ல.

முறையை மாற்றுவது வரம்பைச் சேர்ப்பது அல்ல

RRAS இல் ஒரு ஒதுக்கீட்டு முறையும் வரம்புகளின் தொகுப்பும் உள்ளன. DHCP இலிருந்து நிலையான குளத்திற்கு மாறுவது முறை மாற்றம். நிலையான குளம் ஏற்கனவே செயலில் இருக்கும்போது மற்றொரு தொகுதியைச் சேர்ப்பது வரம்பு மாற்றம்.

எதையும் இயக்கும் முன் இரண்டு செயல்பாடுகளையும் முன்னோட்டமிட்டு, சேவையகத்தின் தற்போதைய நிலையுடன் எது பொருந்துகிறது என்பதைப் படியுங்கள்:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

சேவையகம் இன்னும் DHCP ஒதுக்கீட்டில் இருந்தால் இரண்டாவது cmdlet தோல்வியடையும் அல்லது பயன்படுத்த முடியாத குளத்தை உருவாக்கும். முதல் ஒன்று ஏற்கனவே உள்ள குளத்தை விரிவுபடுத்துவதற்குப் பதிலாக முறையை மாற்றுகிறது. எந்த முன்னோட்டமும் எதையும் பயன்படுத்தாது, எனவே பொருந்துவதை இயக்கி, பின்னர் விளைந்த குளத்தை கன்சோலில் உறுதிப்படுத்துங்கள். சேவையகம் எந்த நிலையில் உள்ளது என்பது உறுதியாகத் தெரியவில்லை என்றால், IPv4 பண்புகள் பக்கத்தில் ஒதுக்கீட்டு முறையைப் படித்து, அமைக்கப்பட்ட வரம்புகளைப் பட்டியலிடுங்கள்:

Get-VpnIPAddressRange

காலியான வரம்புப் பட்டியலுடன் DHCP முறை என்றால் முதல் முன்னோட்டம் பொருந்தும். ஏற்கனவே உள்ள வரம்புடன் நிலையான முகவரிக் குளம் என்றால் இரண்டாவது பொருந்தும்.

அமைப்புக்குத் தேவைப்படக்கூடிய சேவை மறுதொடக்கத்தைக் கணக்கில் கொள்ளுங்கள், இணைந்த வாடிக்கையாளர்கள் உடனடியாக மறுஎண்ணிடல் செய்யப்படுவார்கள் என்று கருத வேண்டாம். மீண்டும் இணையும் வரை பழைய முகவரியை வைத்திருக்கும் வாடிக்கையாளர் சாதாரணமாக நடந்துகொள்கிறார். மீண்டும் இணைவது ஏற்கக்கூடிய ஒரு சாளரத்திற்கு மாற்றத்தைத் திட்டமிடுங்கள்.

LAN க்கு திரும்பும் பாதை தேவை

LAN 10.60.0.0/24 என்றும் RRAS சேவையகம் அதில் 10.60.0.10 என்றும் வைத்துக்கொள்ளுங்கள். அந்த LAN இல் 10.250.50.0/24 இல் உள்ள வாடிக்கையாளருக்குப் பதிலளிக்கும் புரவலருக்கு RRAS சேவையகம் வழியாகக் குளத்திற்குப் பாதை தேவை. அந்தப் பாதை இல்லாவிட்டால் கோரிக்கை வந்து சேர்கிறது, பதில் இறந்துவிடுகிறது.

புரவலரின் இயல்புநிலை நுழைவாயில் வேறு திசைவழியாக்கி என்றால், அந்தத் திசைவழியாக்கிக்கு VPN முன்னொட்டிற்கான திரும்பும் பாதை தேவை. RRAS சேவையகத்தில் உள்ள நிலையான பாதை இங்கே உதவாது; திரும்பும் பாதை LAN நுழைவாயிலைக் கொண்ட சாதனத்தில் இருக்க வேண்டும், எனவே தளம் பயன்படுத்துவதற்கு ஏற்ப அதை வழிமாற்றல் அட்டவணையிலோ மாறும் வழிமாற்றல் செயல்முறையிலோ சேர்க்கவும்.

புதிய மூல வரம்பிற்கு எதிராகப் புரவலரின் தீச்சுவர் மற்றும் எந்தவொரு பிணைய அணுகல் விதிகளையும் சரிபார்க்கவும். பழைய வாடிக்கையாளர் வரம்பிற்காக எழுதப்பட்ட விதிகள் ஒதுக்கீடு வெற்றியடைந்தாலும் புதியதை நிராகரிக்கின்றன. LAN நோக்கிய வாடிக்கையாளர் பாதைகளும் DNS தீர்வும் தனித்தனி தேவைகள், சுரங்கப்பாதை ஆரோக்கியமாகத் தெரியும்போது இரண்டும் தோல்வியடையலாம். ஒவ்வொன்றையும் தனித்தனியாகச் சோதியுங்கள்.

பழையதை நீக்கும் முன் புதிய குளத்தை ஒரு சாதனத்தில் நிரூபியுங்கள்

நீங்கள் கட்டுப்படுத்தும் ஒரு அங்கீகாரத்தை எடுத்து, மீண்டும் இணைந்து வாடிக்கையாளர் பெற்ற குள முகவரியைப் படியுங்கள். அந்த ஒரு எண்ணே ஒதுக்கீட்டை வழிமாற்றலிலிருந்து பிரிக்கிறது. பின்னர் பெயரிடப்பட்ட பயன்பாட்டை இயக்கி, திரும்பும் போக்குவரத்தைக் கவனித்து, நிராகரிக்கப்பட்டே இருக்க வேண்டிய இலக்கை முயற்சியுங்கள். மூன்று அவதானிப்புகள், மூன்று வெவ்வேறு தோல்வி முறைகள்.

பெயர் தீர்வு அதற்கே உரிய சோதனைக்குத் தகுதியானது: IP வழியாக அணுகல் வேலை செய்யலாம், ஆனால் வாடிக்கையாளரின் DNS இன்னும் அவர் அடைய முடியாத தீர்வியை நோக்கிக் காட்டுகிறது. LAN இல் உள்ள DNS சேவையகத்தை அடைய முடியும், வாடிக்கையாளருக்கு அங்கு பாதை இருந்தால் மட்டுமே, மேலும் சேவையகம் புதிய வரம்பிலிருந்து வினவல்களை ஏற்றுக்கொண்டால் மட்டுமே. குளம் நகரும் போது இரண்டும் பொதுவான தவறுகள்.

செயலில் உள்ள அமர்வுகளையும் பராமரிப்பு செயல்முறையையும் கணக்கில் கொண்ட பின்னரே பழைய வரம்புகளையும் அவற்றின் விதிவிலக்குகளையும் நீக்குங்கள். புதிய முகவரியுடன் இணைந்த வாடிக்கையாளர் ஒதுக்கீட்டை நிரூபிக்கிறார், அணுகல் கொள்கையை அல்ல. அதைப் பயன்படுத்திய கடைசி அமர்வு முடியும் வரை பழைய வரம்பை ஆவணப்படுத்தி வையுங்கள்.

மூன்று அவதானிப்புகளால் முடிவைச் சரிபார்க்கவும்

ஏற்றுக்கொள்வதற்கு மூன்று உண்மைகள் தேவை: வாடிக்கையாளரிடம் புதிய குளத்திலிருந்து முகவரி உள்ளது, LAN புரவலர் அவரை அடைந்து பதிலைப் பெற முடியும், நிராகரிக்கப்பட்ட இலக்கு இன்னும் நிராகரிக்கப்பட்டுள்ளது. ஒவ்வொன்றுக்கும் அதன் சொந்த சரிபார்ப்பு உள்ளது, எனவே தோல்வி ஒதுக்கீடு, வழிமாற்றல் அல்லது கொள்கையைச் சுட்டுகிறது. அவற்றை அந்த வரிசையில் இயக்குங்கள்.

வாடிக்கையாளரிடமிருந்து, முகவரியையும் ஒரு LAN புரவலருக்கான பாதையையும் உறுதிப்படுத்துங்கள்:

ipconfig | findstr /i "IPv4"
route print -4

LAN புரவலரிடமிருந்து, ஒரே கட்டத்தில் திரும்பும் பாதையையும் கொள்கையையும் உறுதிப்படுத்துங்கள். ping தோல்வியடைந்தாலும் பயன்பாடு செயல்பட்டால், விடுபட்ட பகுதி பாதை அல்ல, ICMP விதியாக இருக்கலாம். இரண்டும் தோல்வியடைந்தால், VPN ஐத் திருத்தும் முன் புரவலரில் உள்ள பாதையைப் படியுங்கள். மூன்று முடிவுகளையும் மாற்ற டிக்கெட்டில் பதிவு செய்யுங்கள், அடுத்தவர் சான்றுகளிலிருந்து தொடங்கட்டும்.