LAN ஹோஸ்ட் OpenVPN கிளையண்ட் முகவரிக்கு ஏன் ARP அனுப்புகிறது

LAN ஹோஸ்ட் மற்றும் VPN கிளையண்ட் இடையேயான அணுகல் சிக்கல்கள் பெரும்பாலும் முகவரித் திட்டத்திற்கே திரும்புகின்றன. அந்த ஹோஸ்டுக்கு 10.0.100.0/22 இல் ஒரு இடைமுகம் கொடுங்கள்; அது 10.0.100.0 முதல் 10.0.103.255 வரையிலான ஒவ்வொரு முகவரியையும் நேரடியாக இணைந்ததாகக் கருதும், 10.0.101.0/24 இல் அமைதியாக வைக்கப்பட்ட கிளையண்ட் தொகுப்பு உட்பட. பதில் ஒருபோதும் ரவுட்டருக்குச் செல்லாது, ஏனெனில் ஹோஸ்டின் பார்வையில் எந்த ரவுட்டரும் ஈடுபடுவதில்லை. பாக்கெட் ஒரு அண்டைக்கு முகவரியிடப்பட்டு கம்பியில் கோரப்படுகிறது.

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

/24 ஐ விழுங்கும் /22

முன்னொட்டை வரம்பாகப் படியுங்கள், சரமாக அல்ல. ஒரு /22 இல் 1024 முகவரிகள் உள்ளன, 10.0.100.0/22 10.0.100.0 முதல் 10.0.103.255 வரை பரவுகிறது, எனவே 10.0.101.0/24 இல் உள்ள தொகுப்பு முழுவதுமாக அதற்குள் உள்ளது. இந்தப் பிழை மதிப்பாய்வைத் தாண்டுகிறது, ஏனெனில் தொகுப்பின் முதல் ஆக்டெட்டுகள் LAN இன் முதல் ஆக்டெட்டுகளிலிருந்து வேறுபட்டுத் தெரிகின்றன, மூன்றாவது ஆக்டெட் மட்டுமே இந்த அடக்கத்தை வெளிப்படுத்துகிறது. இரண்டு வரம்புகளையும் எண்களில் எழுதுங்கள், அவற்றைத் தனித்தனியாக அறிவிக்கும் முன்.

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

நேரடி இணைப்பு என்பது ARP, ரவுட்டிங் அல்ல

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

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

TUN, TAP மற்றும் ஒவ்வொன்றும் எதைச் சுமக்கிறது

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

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

ஒன்றுடன் ஒன்று மேலிட முடியாத தொகுப்பை வடிவமைக்கவும்

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

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

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