வெளிப்படையான TCP-இலிருந்து-SOCKS அனுப்புதலில் மூல இலக்குகள்

ஒரு தீச்சுவர் TCP இணைப்பு எங்கு வந்து சேருகிறது என்பதை மாற்றலாம். ஆனால் அந்த மாற்றத்தால் மட்டும் அது மூல பயன்பாட்டுக்கு SOCKS பேசக் கற்பிக்க முடியாது.

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

காணாமல் போன கூறு ஒரு மொழிபெயர்ப்பாளர்

வெளிப்படையான TCP-இலிருந்து-ப்ராக்ஸி கூறு அந்த இடைமுகங்களுக்கு இடையே அமைகிறது. பயன்பாடு முதலில் கோரிய இலக்கை அது கண்டறிகிறது, பொருத்தமான SOCKS அல்லது HTTP CONNECT அமர்வை நிறுவுகிறது, பின்னர் உருவான ஓட்டத்தின் மேல் பயன்பாட்டு தரவை அனுப்புகிறது.

அதன் Linux iptables பாதையில், redsocks மூலம் பாதுகாக்கப்பட்ட இலக்கை SO_ORIGINAL_DST மூலம் பெறுகிறது. பிற இயக்க முறைமைகளும் திசைதிருப்பல் முறைகளும் வெவ்வேறு இயங்குமுறைகளைப் பயன்படுத்துகின்றன. இது திசைதிருப்பியின் மற்றும் வலைப்பிணைப்பு அமைப்பின் பண்பு, சாதாரண SOCKS வாடிக்கையாளரின் அம்சம் அல்ல.

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

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

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