SOCKS5 வழியாக OpenVPN: பதிப்பு, பரிமாற்றம், DNS ஆகியவற்றைப் பொருத்துங்கள்
SOCKS சங்கிலி தோல்வியடைவது ப்ராக்ஸி பதிப்பு, பரிமாற்றம் அல்லது DNS பாதை ஒத்துப்போகாதபோதுதான். SOCKS5-ஐப் பொருத்துங்கள், TCP-ஐக் கொண்டு செல்லுங்கள், சங்கிலியை ஒரு பெயர்வெளிக்குள் வையுங்கள்.
இந்தப் பணிநிலையத்திலிருந்து வெளியேறும் ஒரு பாதை SOCKS ப்ராக்ஸி, அதன் பின்னால் OpenVPN பயனுள்ள விவரம் எதுவும் இல்லாமல் இணைப்பு நேரம்முடிவைத் தெரிவிக்கிறது. அதே கணினியின் உலாவி அந்தப் ப்ராக்ஸி வழியாக வேலை செய்கிறது, சான்றுகள் சரியானவை, போர்ட் பதிலளிக்கிறது. மூன்று விஷயங்கள் முதலில் சரிபார்க்கும் அளவுக்கு வேறுபடுகின்றன: ப்ராக்ஸி பேசும் SOCKS பதிப்பு, கிளையண்ட் தேர்ந்த பரிமாற்றம், மற்றும் பெயர் பகுப்பாய்வு நடக்கும் இடம். ஃபயர்வால் குற்றம் என்று முடிவெடுக்கும் முன் ஒவ்வொன்றையும் உறுதிப்படுத்துங்கள்.
ஃபயர்வாலுக்கு முன் SOCKS பதிப்பைப் பொருத்துங்கள்
சமூக OpenVPN socks-proxy-க்கு SOCKS5 பேசுகிறது. SOCKS4 மட்டும் வழங்கும் ப்ராக்ஸியில் அதை வைத்தால் TCP இணைப்பு திறந்து பிறகு நிலைத்து நிற்கும், ஏனெனில் கிளையண்ட் மறுமுனை ஒருபோதும் பகுக்காத வாழ்த்துக்கு பதிலை எதிர்பார்க்கிறது. வெளியிலிருந்து இந்த நிற்பது வடிகட்டப்பட்ட போர்ட்டைப் போலவே தெரிகிறது, அதனால்தான் பதிப்புக் கேள்வி எந்த ஃபயர்வால் விதிக்கும் முன் வருகிறது. SOCKS அறிந்த ஒரு பெறுதல் அதை ஒரே கட்டளையில் தீர்க்கிறது.
curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
நிறைவேறிய கோரிக்கை ஒரே நேரத்தில் இரண்டை நிரூபிக்கிறது: ப்ராக்ஸி SOCKS கோரிக்கையை ஏற்றது, பெயரைத் தீர்த்தது. URL திட்டம் தேவையில்லை, ஏனெனில் curl வெற்று ஹோஸ்ட்டை HTTP ஆகக் கருதுகிறது, இது இந்தச் சோதனைக்குப் போதும்.
அந்தப் பெறுதல் கிளையண்ட் பதிவு மறைக்கும் தோல்வியையும் விலக்குகிறது. ப்ராக்ஸி உலாவிக்கு அனுமதி அளித்தும் VPN இலக்கை மறுக்கலாம், அப்போது மறுப்பு CONNECT-இல் நடக்கிறது, எந்த VPN அங்கீகாரத்துக்கும் முன். OpenVPN நேரம்முடிவை மட்டும் தெரிவிக்கிறது, எனவே ப்ராக்ஸியின் சொந்தப் பதிலே உங்களுக்குத் தேவையான ஆதாரம்.
பரிமாற்றம் இரு பக்கமும் TCP ஆக இருக்க வேண்டும்
SOCKS5 இங்கே TCP ஸ்ட்ரீமைக் கொண்டு செல்கிறது, எனவே சுரங்கப்பாதைக்கே proto tcp-client தேவை. இன்னும் UDP-இல் அமைக்கப்பட்ட சுயவிவரம் இந்தப் பாதையில் வேலை செய்யாது, ஏனெனில் கிளையண்ட் நெறிமுறையின் UDP சங்க முறையைப் பயன்படுத்தாது. சுயவிவரத்தைத் திருப்புவது உண்மையான மாற்றம், முறைப்படியானது அல்ல: தொலைமுனை அதே போர்ட்டில் TCP-இல் கேட்க வேண்டும். பின்னர் சுமை TCP-க்குள் TCP ஆகிறது, அங்கு தொலைந்த பிரிவு இருமுறை மீண்டும் அனுப்பப்படுகிறது, வேகம் குறைகிறது, இதை ஊடாடும் அமர்வுகள் பெரிய பரிமாற்றங்களை விட மிக அதிகமாக உணர்கின்றன.
proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050
இந்த உத்தரவு ப்ராக்ஸி ஹோஸ்ட், விருப்பப் போர்ட் மற்றும் விருப்பச் சான்றுக் கோப்பை எடுக்கிறது. அவற்றைச் சுயவிவரத்திலேயே வையுங்கள், வேறு இடத்தில் வைக்கப்பட்ட நகலும் அதே விதமாக நடந்துகொள்ளும்.
முழுச் சங்கிலியையும் ஒரு கொள்கலனில் அடக்குங்கள்
சங்கிலியை ஹோஸ்ட்டில் செய்வது என்பது அதன் இயல்புநிலை பாதையைக் கைப்பற்றி resolver-ஐ பிறகு யாரும் விளக்க முடியாத நிலையில் விடுவது. பெயர்வெளி அல்லது கொள்கலன் அதை அடக்குகிறது, எனவே ஹோஸ்ட் தன் பாதையை வைத்துக்கொள்ளும் அதே வேளையில் SOCKS தாவலும் சுரங்கப்பாதையும் சேர்ந்து வாழ்கின்றன. அதற்குள் சுரங்க சாதனம், அச்சாதனத்தை அமைக்கும் உரிமைகள், அணுகக்கூடிய ப்ராக்ஸி இல்லாமல் எதுவும் எழாது. Compose சேவை இதை cap_add: NET_ADMIN மற்றும் bind-ஏற்றப்பட்ட /dev/net/tun மூலம் பெறுகிறது.
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
இந்த இணை கொள்கலனை privileged ஆக இயக்குவதை விட குறுகியது, சாதன அணுகலின் தேவையான முழுப் பகுதியும் இதுவே. Tor கிளையண்ட் அல்லது தனிக் கொள்கலன் கேட்பவரை வழங்கலாம். இரு நிலைகளிலும் அதை loopback-இல் கட்டுங்கள், ப்ராக்ஸியை வலையமைப்பில் வெளிப்படுத்துவதற்குப் பதிலாக பெயர்வெளியிலிருந்து ஹோஸ்ட் வழியாக அதை அணுகுங்கள்.
பெயர் பகுப்பாய்வுதான் தனிமைப்படுத்தல் தோல்வியடையும் இடம்
பாக்கெட்டுகளை எடுத்துச் சென்று கொண்டே ஹோஸ்ட்டின் resolver-ஐக் கேட்கும் சுரங்கப்பாதை எதையும் தனிமைப்படுத்தவில்லை. இரண்டு விஷயங்கள் தனிமைப்படுத்தலை உண்மையாக்குகின்றன: பெயர்வெளிக்கு சொந்த resolver இருப்பது, அதன் வினவல்கள் ப்ராக்ஸி அல்லது சுரங்கப்பாதை வழியாகச் செல்வது, ஒருபோதும் இயற்பியல் இடைமுகம் வழியாகச் செல்லாதது. சோதனைக்கு இரண்டு பெயர்களைப் பயன்படுத்துங்கள்: ஒன்று சுரங்கப்பாதைக்குப் பின்னால் மட்டும் உள்ளது, மற்றொன்று அதே பாதையைப் பின்பற்ற வேண்டிய பொது பெயர்.
docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example
தொலைப் பெயர் தீர்ந்து பொது பெயர் தீரவில்லை என்றால், சங்கிலி தேர்ந்தெடுக்கப்பட்டது, உடைந்தது அல்ல, வேறுபாடு ஒவ்வொரு வினவலும் எந்தப் பாதையை எடுத்தது என்பதைச் சொல்கிறது. இரண்டும் ஹோஸ்ட்டில் தீர்ந்து கொள்கலனுக்குள் எதுவும் தீரவில்லை என்றால், கொள்கலன் இன்னும் ஹோஸ்ட்டின் resolver-ஐக் கடன் வாங்குகிறது. கிடைத்த resolver கோப்பைப் பதிவு செய்யுங்கள், ஏனெனில் அதுதான் மாற வேண்டிய அமைப்பு.
ஒவ்வொரு தாவலையும் வரிசையாக நிரூபியுங்கள்
பட்டியல் சிறியது. SOCKS5 கோரிக்கைக்கு பதில் கிடைக்கிறது, சுரங்கப்பாதை ப்ராக்ஸி வழியாக தன் கேட்பவரை அடைகிறது, பெயர்வெளியிலிருந்து வெளியேறும் பாக்கெட்டுகள் தொலைமுனை எதிர்பார்க்கும் முகவரியைக் கொண்டு செல்கின்றன. மேலும் அமைப்புகளை அடுக்குவதற்குப் பதிலாக ஒவ்வொன்றையும் தனித்தனியாக உறுதிப்படுத்துங்கள். கிளையண்ட் இணைந்துள்ளது, எதுவும் நகர்கிறது இல்லை என்று சொல்லும்போது, முறிவு கிட்டத்தட்ட எப்போதும் இரண்டாவது அல்லது மூன்றாவது உண்மையில் இருக்கும்.
curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example
வேலை செய்த கலவையை எழுதி வையுங்கள்: SOCKS பதிப்பு, பரிமாற்றம், resolver மற்றும் பெயர்வெளி அமைப்புகள். இந்தச் சங்கிலியை இரண்டாம் முறை நினைவிலிருந்து தீர்ப்பது குறிப்பை விட அதிகம் செலவாகும். அந்த நான்கு உண்மைகளையும் டிக்கெட்டில் வையுங்கள், அரட்டை இழையில் அல்ல.
இணைந்துள்ளது எனத் தெரிவித்து எதையும் கடத்தாத சங்கிலி, நீங்கள் இன்னும் நிரூபிக்காத தாவலிலேயே பொதுவாகத் தோல்வியடைந்திருக்கும். மற்றொரு அடுக்கைச் சேர்ப்பதற்கு முன் அந்தத் தாவலைச் சோதியுங்கள்.