VPN முகவரி மற்றும் LAN DHCP குத்தகை: சுரங்கப்பாதை IP ஐ யார் வழங்குகிறார்?

வாடிக்கையாளரை இணைத்து Wi-Fi சின்னத்திற்குப் பதிலாக அடாப்டரைப் பாருங்கள். 10.80.0.14 போன்ற முகவரி ஒரு சுரங்கப்பாதையில் இருக்கலாம், அதே நேரத்தில் அலுவலக LAN இல் எந்த DHCP சேவையகமும் அந்தக் குத்தகையை ஒருபோதும் பதிவு செய்யவில்லை. எந்தச் செயல்முறை எண்ணைத் தேர்ந்தெடுத்தது என்பதே சரிசெய்தல் எங்கு தொடங்க வேண்டும் என்பதைத் தீர்மானிக்கிறது.

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

வாடிக்கையாளர் பக்கத்திலிருந்து சுரங்கப்பாதை முகவரியைப் படியுங்கள்

முதல் வரிக்குப் பதிலாக முழுத் தொகுதியையும் படித்தால் Windows வேறுபாட்டைக் காட்டுகிறது. ipconfig /all அடாப்டர் விவரம், இயற்பியல் முகவரி மற்றும் DHCP வரியை அச்சிடுகிறது. PPP அல்லது IKEv2 டயல்-அப் அடாப்டர் பொதுவாக DHCP முடக்கப்பட்டுள்ளதாகத் தெரிவிக்கிறது, ஏனெனில் இணைப்பு LAN சேவையகத்திடமிருந்து குத்தகை எடுப்பதற்குப் பதிலாக டயல் செய்யும் போதே அதன் முகவரியைப் பேச்சுவார்த்தை செய்தது. DHCP இயக்கப்பட்ட சுரங்கப்பாதை அடாப்டர் அசாதாரணமானது மற்றும் தனியாக ஆராயத் தகுந்தது.

Linux அதே தகவலை இரண்டு கருவிகளுக்குப் பிரிக்கிறது. ip -4 addr show dev tun0 முகவரியையும் முன்னொட்டு நீளத்தையும் தருகிறது. nmcli -f IP4 connection show work மதிப்பு இணைப்புச் சுயவிவரத்திலிருந்து, இணைப்பில் நடந்த DHCP பரிமாற்றத்திலிருந்து அல்லது தள்ளப்பட்ட உள்ளமைவிலிருந்து வந்ததா என்பதை வெளிப்படுத்துகிறது. WireGuard மிகத் தெளிவான நிலை, ஏனெனில் இடைமுகம் தோன்றும்போது wg-quick உள்ளமைவுக் கோப்பின் Address வரியைப் பயன்படுத்துகிறது, இணைக்கும் நேரத்தில் எந்தச் சகாவும் எதையும் ஒதுக்குவதில்லை.

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

IKEv2 உள்ளமைவுப் பேலோடு எதைச் சுமக்கிறது

இந்த வேலைக்கு IKEv2 க்கு தனி முறை உள்ளது. RFC 7296, பிரிவு 3.15.1 இல் விவரிக்கப்பட்ட உள்ளமைவுப் பேலோடு INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS மற்றும் அவற்றின் IPv6 இணைகள் போன்ற பண்புகளைச் சுமக்கிறது. விருப்பம் இல்லாதபோது வாடிக்கையாளர் பூஜ்ய நீள மதிப்புள்ள பண்பை அனுப்புகிறது, பதிலளிப்பவர் பயன்படுத்த விரும்பும் மதிப்பைத் திருப்பித் தருகிறார். அந்தப் பரிமாற்றம் ஏற்கனவே மறையாக்கப்பட்ட IKE_AUTH உள்ளே நடக்கிறது, எனவே எந்த DHCP ஒளிபரப்பும் சுரங்கப்பாதையைக் கடப்பதில்லை.

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

வலையமைப்பு முகமூடிப் பண்பு நடைமுறையில் விருப்பத்தேர்வு. பலப் பயன்பாடுகள் ஒரு முகவரியை மட்டும் திருப்பித் தந்து, வாடிக்கையாளர் புரவலன் பாதையை நிறுவ அனுமதிக்கின்றன, அதனால் அதே குளம் ஒரு வாடிக்கையாளரில் /32 ஆகவும் மற்றொன்றில் /24 ஆகவும் தோன்றலாம்.

LAN DHCP வரம்பும் VPN குளமும் மோதும் இடம்

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

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

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

முகவரி எந்தச் செயல்முறைக்குச் சொந்தம் என்பதைச் சரிபார்க்கவும்

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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