VPN வாடிக்கையாளர்கள் சேவையகத்தை அடைகிறார்கள், LAN-ஐ அல்ல: எந்த தீர்வு?

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

முதலில் எந்தத் திசை பழுதடைந்துள்ளது என்பதை உறுதிப்படுத்துங்கள்

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

முதல் கேள்வி: தொலைதூர LAN-இன் திசைவியைத் திருத்த முடியுமா?

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

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

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

இரண்டாவது கேள்வி: LAN வாடிக்கையாளர் முகவரிகளைப் பார்ப்பதை நிறுத்த முடியுமா?

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

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

மூன்றாவது கேள்வி: சேவையகம் தானே இன்னொரு சுரங்கப்பாதையின் வாடிக்கையாளரா?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

பின்னர் இரு திசைகளையும் இரு அளவுகளையும் சரிபாருங்கள்

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

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

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