Սկզբնական նպատակակետերը TCP-ից SOCKS թափանցիկ փոխանցման մեջ

Հրային պատը կարող է փոխել, թե որտեղ է վայրէջք կատարում TCP կապը։ Սակայն միայն այդ փոփոխությամբ այն չի կարող սկզբնական հավելվածին սովորեցնել խոսել SOCKS։

Սովորական SOCKS սերվերը սպասում է բանակցության, որը նկարագրում է պահանջված նպատակակետը։ Վստահված սերվերի մասին չտեղեկացված հավելվածը փոխարենը անմիջապես ուղարկում է իր սեփական արձանագրության բայթերը։ Ուղղեք այդ բայթերն ուղիղ SOCKS լսողին, և երկու կողմերը կտարաձայնվեն առաջին հաղորդագրության շուրջ։

Բացակայող բաղադրիչը թարգմանիչն է

TCP-ից վստահված սերվեր թափանցիկ բաղադրիչը տեղակայված է այդ միջերեսների միջև։ Այն հայտնաբերում է այն նպատակակետը, որը հավելվածը սկզբնապես պահանջել էր, հաստատում է համապատասխան SOCKS կամ HTTP CONNECT նստաշրջանը, ապա փոխանցում է հավելվածի տվյալները ստացված հոսքի վրայով։

Իր Linux iptables ուղու վրա redsocks-ի ելակետային կոդը վերցնում է պահպանված նպատակակետը SO_ORIGINAL_DST-ի միջոցով։ Այլ օպերացիոն համակարգեր և վերահասցեավորման եղանակներ օգտագործում են տարբեր մեխանիզմներ։ Սա վերահասցեավորիչի և ցանցի կարգավորման հատկություն է, ոչ թե սովորական SOCKS հաճախորդի գործառույթ։

Սկզբնական նպատակակետի մասին տեղեկությունը նաև բացատրում է, թե ինչու վերահասցեավորման կանոնը վստահված սերվերի հոսթից անկապ դարպաս տեղափոխելը միշտ չէ, որ համարժեք է։ Ընդունող գործընթացին անհրաժեշտ են այն մետատվյալները, որոնք պահանջում է նրա ընդհատման եղանակը։ Այլ տեղ վերագրված հասցեն գուցե այլևս չտրամադրի այդ տեղեկությունը սպասվող ձևով։

Թարգմանչի շրջանակը պահեք հստակ։ Աշխատող վերահասցեավորված TCP կապը չի ապացուցում կամայական UDP-ի, ICMP-ի կամ յուրաքանչյուր լուծիչ ուղու աջակցությունը։ Վերին վստահված սերվերի արձանագրությունը և թարգմանչի իրականացումը դեռևս սահմանում են աջակցվող գործողությունները։

Երբ կարգավորումը ձախողվում է կապից անմիջապես հետո, ստուգեք արձանագրության սահմանը նախքան մուտքի կանոնները լայնացնելը։ Կատարյալ հասանելի SOCKS լսողը կարող է մերժել բայթեր, որոնք երբեք SOCKS հարցում չեն եղել։