Redsocks லூப்பபேக்கில் கேட்கிறது ஆனால் VPN போக்குவரத்து என்றும் வருவதில்லை

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

திருப்பிவிடப்பட்ட பாக்கெட் உண்மையில் எங்கே விழுகிறது

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

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

கேட்பானையும் திருப்பிவிடல் விதியையும் சேர்ந்து படியுங்கள்

சாக்கெட் அட்டவணையையும் nat விதிகளையும் ஒரே பாஸில் அச்சிடுங்கள், ஏனெனில் யாரும் உரிமை கொள்ளாத போர்ட்டைச் சுட்டும் விதி தவறான முகவரியைச் சுட்டும் விதியைப் போலவே தெரிகிறது. sudo ss -ltnp | grep redsocks பிணைப்பு முகவரியையும் உரிமையாளர் செயல்முறையையும் காட்டுகிறது. sudo iptables -t nat -S PREROUTING REDIRECT இலக்கைக் காட்டுகிறது, sudo iptables -t nat -L PREROUTING -v -n அதற்கு ஏதேனும் பொருந்தியதா எனக் காட்டுகிறது.

REDSOCKS எனப்படும் பயனர் சங்கிலிக்குத் தாவுவது, அந்தச் சங்கிலி இல்லாமலும், நோக்கமிடப்பட்ட விலக்குகளையும் REDIRECT செயலையும் கொண்டிருக்காமலும் எதையும் சாதிக்காது. பெயரே வேலை செய்கிறது என்று கருதுவதற்குப் பதிலாக sudo iptables -t nat -S REDSOCKS உடன் அது தாவும் சங்கிலியைப் படியுங்கள்.

பின்னர் இரண்டு மதிப்புகளையும் ஒப்பிடுங்கள். விதி போர்ட் 12345 இல் உள்ள கேட்வே முகவரிக்குத் திருப்பிவிட்டு, கேட்பான் 127.0.0.1:12345 எனத் தெரிவித்தால், அந்த முரண்பாடு கூடுதல் கண்டறிதல் இல்லாமலே தோல்வியை விளக்குகிறது.

குறுகலாகப் பிணையுங்கள், பின்னர் எது அதை அடையலாம் என்பதை வரம்புபடுத்துங்கள்

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

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

கிளையண்டிலிருந்து புதிய இணைப்புடன் அதை நிரூபியுங்கள்

கேட்வேயில் உள்ள ஷெல்லிலிருந்து அல்ல, உண்மையான VPN கிளையண்டிலிருந்து புதிய TCP இணைப்புடன் சோதியுங்கள். கிளையண்டில் curl -sS -o /dev/null -w '%{http_code}\n' http://example.com திருப்பிவிடப்பட்ட பாதையை ஆரம்பத்திலிருந்து இறுதி வரை இயக்குகிறது.

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

இறுதியாக, இந்தப் பாதை எதை மறைக்கவில்லை என்பதை நினைவில் கொள்ளுங்கள். சாதாரண redsocks TCP திருப்பிவிடல் UDP, QUIC அல்லது DNS ஐ SOCKS போக்குவரத்தாக மாற்றாது, தனிப்பட்ட இலக்குகளுக்கு பொதுவாக வெளிப்படையான விலக்குகள் தேவை. வெற்றிகரமான உள்ளூர் சோதனை ஒருபோதும் பிரச்சினையாக இல்லாத லூப்பபேக் பாதையை மட்டுமே நிரூபிக்கிறது.