உங்கள் VPN குளம் LAN இன் DHCP வரம்பு அல்ல: அது ஏன் உடைகிறது

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

இரு ஒதுக்கீட்டாளர்கள், ஒரு முகவரி இடம்

LAN இன் DHCP சேவையகம் எந்த முகவரிகளை எந்த MAC முகவரிக்கு குத்தகைக்கு விட்டது என்பதை அறிந்து, ARP மூலம் அவற்றைப் பாதுகாக்கிறது. VPN சேவையகத்திற்கு அதன் சொந்தக் குளம் உண்டு, அந்தக் குத்தகைகள் பற்றி எதுவும் தெரியாது. இரண்டும் தவறில்லை; அவை ஒன்றுக்கொன்று அறிமுகப்படுத்தப்பட்டதே இல்லை.

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

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

வழிப்படுத்தி ஏன் VPN முகவரிகளை வழங்குவதில்லை

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

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

அதே தர்க்கம் DHCP வரம்பை மாற்றினால் ஒருபோதும் முகவரி பெறாத VPN வாடிக்கையாளர் ஏன் சரியாகாது என்பதை விளக்குகிறது. வாடிக்கையாளர் LAN சேவையகத்தைக் கேட்கவில்லை, வரம்பில் எவ்வளவு திருத்தினாலும் அவரைக் கேட்க வைக்க முடியாது.

ஒன்றிணைவு மெதுவான வலைப்பிணையமாக அல்ல, முரண்பாடாகத் தெரிகிறது

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

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

திரும்பும் பாதை தனி சிக்கல்

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

எதையும் மாற்றுவதற்கு முன் பாதையை இரு திசைகளிலும் படியுங்கள். நுழைவாயிலில் கர்னல் வாடிக்கையாளர் முகவரிக்கு எந்த இடைமுகத்தைப் பயன்படுத்தும் என்று கேளுங்கள்; வாடிக்கையாளரில் LAN முகவரிக்கு எந்தப் பாதையைப் பயன்படுத்துகிறது என்று கேளுங்கள்.

இந்தக் கட்டளைகள் நுழைவாயிலில் அனுப்பு முடிவையும் நகலையை வெளிப்படுத்தும் அண்டைப் பதிவுகளையும் காட்டுகின்றன:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

முதல் கட்டளை சுரங்கப்பாதை இடைமுகத்துடன் பதிலளித்தால், திரும்பும் பாதை உள்ளது. அது LAN இடைமுகத்துடன் பதிலளித்தால், வழிப்படுத்தி வாடிக்கையாளர் கம்பியில் இருப்பதாக நம்பி அவருக்காக ARP செய்ய முயலும்.

பால வடிவமைப்புகள் உள்ளன, ஆனால் அவற்றைத் தேர்ந்தெடுக்க வேண்டும்

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

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

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