LAN முகவரி உள்ள VPN கிளையண்ட் LAN-இல் இல்லை

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

புராணக்கதை: ஒரே முன்னொட்டு என்பது ஒரே பிரிவு

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

சேவையகம் 10.50.0.200-க்கு அனுப்பும்போது, இலக்கை தன் மாஸ்குடன் ஒப்பிட்டு, முகவரி on-link என முடிவெடுத்து, அதைக் கொண்டிருக்கும் வன்பொருள் முகவரியை உள்ளூர் பிரிவிடம் கேட்கிறது. அந்தக் கோரிக்கை Ethernet இடைமுகத்தின் வழியாக வெளியேறுகிறது, அதைக் கேட்க VPN கிளையண்ட் அங்கு இல்லை.

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

உள்ளூர் ஹோஸ்ட் முகவரியுடன் உண்மையில் என்ன செய்கிறது

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

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

proxy ARP அடுத்த பாய்ச்சலை எவ்வாறு வழங்குகிறது

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

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

இது கிளையண்ட்டை LAN-இல் பாலமாக இணைப்பதற்குச் சமமானதல்ல. கேட்வே இன்னும் சரியான செயலில் உள்ள அமர்வுக்கு பாக்கெட்டை அனுப்ப வேண்டும், அதன் வழியமைப்பும் ஃபயர்வால் கொள்கையும் இன்னும் சேவையை அனுமதிக்க வேண்டும். proxy ARP அண்டைக் கோரிக்கைக்கு யார் பதிலளிக்கிறார்கள் என்பதை மாற்றுகிறது, யாருக்குப் பேச அனுமதி உண்டு என்பதை அல்ல.

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

proxy ARP உங்களுக்குத் தராதது

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

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

மேலும் இது LAN-இன் உரிமையாளருடன் ஒருங்கிணைப்பதற்கான தேவையை நீக்காது. முகவரித் திட்டத்தின் உரிமையாளரை ஆச்சரியப்படுத்தும் proxy ARP பதிவு அமைதியான ஒரு வாரத்திற்காகக் காத்திருக்கும் ஆதரவு நிகழ்வு.

தனியாக வழியமைக்கப்பட்ட குளத்துடன் ஒப்பீடு

மாற்று வழி, VPN கிளையண்ட்களுக்கு அவர்களின் சொந்த முன்னொட்டைக் கொடுத்து, LAN ஹோஸ்ட்கள் அங்கு வழியமைக்க அனுமதிப்பது. பின்னர் சேவையகம் தன் கேட்வேக்கு off-link பதில்களை அனுப்புகிறது, கேட்வே முன்னொட்டை VPN முடிவுப் புள்ளிக்கு வழியமைக்கிறது, LAN பிரிவில் அண்டை-தீர்வே தேவையில்லை. இது கடன் வாங்கிய முகவரியும் proxy பதிலும் சேர்ந்ததைவிடக் குறைவான நகரும் பகுதிகள்.

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

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