Oarspronklike bestimmingen yn transparante TCP-nei-SOCKS-trochstjoering

In fjoermuorre kin feroarje wêr't in TCP-ferbining lânet. Mar mei dy feroaring allinnich kin er de oarspronklike applikaasje net leare om SOCKS te praten.

In gewoane SOCKS-tsjinner ferwachtet in ûnderhanneling dy't de oanfrege bestimming beskriuwt. In applikaasje dy't de proxy net ken, stjoert ynstee daliks syn eigen protokolbytes. Ferwiis dy bytes streekrjocht nei in SOCKS-harker en de beide kanten binne it net iens oer it earste berjocht.

It ûntbrekkende ûnderdiel is in oersetter

In transparant TCP-nei-proxy-ûnderdiel sit tusken dy ynterfaces. It ûntdekt de bestimming dy't de applikaasje oarspronklik oanfrege, set de passende SOCKS- of HTTP CONNECT-sesje op en stjoert dan applikaasjegegevens troch oer de ûntstiene stroom.

Op syn Linux iptables-paad hellet de redsocks-boarne de bewarre bestimming op mei SO_ORIGINAL_DST. Oare bestjoeringssystemen en trochferwizingsmetoaden brûke oare meganismen. Dit is in eigenskip fan de trochferwizer en de netwurkynstelling, net in gewoane funksje fan in SOCKS-klant.

Ynfomaasje oer de oarspronklike bestimming ferklearret ek wêrom't it ferpleatsen fan in trochferwizingsregel fan de proxy-host nei in net-ferbûn gateway net altyd gelykweardich is. It ûntfangende proses hat de metadata nedich dy't syn ûnderskeppingsmodus easket. In adres dat earne oars oerskreaun is, jout dy ynformaasje miskien net mear yn 'e ferwachte foarm.

Hâld it berik fan de oersetter dúdlik. In wurkjende trochferwiisde TCP-ferbining bewiist gjin stipe foar willekeurige UDP, ICMP of elk resolver-paad. It protokol fan 'e boppeste proxy en de ymplemintaasje fan 'e oersetter bepale noch hieltyd hokker operaasjes stipe wurde.

As in ynstelling fuort nei de ferbining mislearret, kontrolearje dan de protokolgrins foar't jo tagongsregels ferbreedzje. In folslein berikbere SOCKS-harker kin bytes ôfwize dy't nea in SOCKS-oanfraach wiene.