Oorspronklike bestemmings in deursigtige TCP-na-SOCKS-aansturing

'n Brandmuur kan verander waar 'n TCP-verbinding beland. Dit kan nie, deur daardie verandering alleen, die oorsprongtoepassing leer om SOCKS te praat nie.

'n Gewone SOCKS-bediener verwag 'n onderhandeling wat die versoekte bestemming beskryf. 'n Toepassing wat nie van die instaanbediener weet nie, stuur eerder dadelik sy eie protokolgrepe. Herlei daardie grepe reguit na 'n SOCKS-ontvanger en die twee kante verskil oor die eerste boodskap.

Die ontbrekende komponent is 'n vertaler

'n Deursigtige TCP-na-instaanbediener-komponent sit tussen daardie koppelvlakke. Dit ontdek die bestemming wat die toepassing oorspronklik versoek het, vestig die gepaste SOCKS- of HTTP CONNECT-sessie en stuur dan toepassingsdata oor die resulterende stroom.

Op sy Linux iptables-roete haal die redsocks-bron die bewaarde bestemming met SO_ORIGINAL_DST op. Ander bedryfstelsels en herleidingsmetodes gebruik ander meganismes. Dit is 'n eienskap van die herleier en netwerkinstelling, nie 'n gewone SOCKS-kliëntfunksie nie.

Inligting oor die oorspronklike bestemming verduidelik ook waarom dit nie altyd gelykwaardig is om 'n herleidingsreël van die instaanbediener-gasheer na 'n onverwante poort te skuif nie. Die ontvangende proses benodig die metadata wat sy onderskappingsmodus vereis. 'n Adres wat elders herskryf is, verskaf dalk nie meer daardie inligting in die verwagte vorm nie.

Hou die omvang van die vertaler duidelik. 'n Werkende herleide TCP-verbinding bevestig nie ondersteuning vir willekeurige UDP, ICMP of elke resolver-roete nie. Die opstroom-instaanbedienerprotokol en die vertaler se implementering bepaal steeds die ondersteunde bewerkings.

Wanneer 'n opstelling onmiddellik na die verbinding misluk, kontroleer die protokolgrens voordat toegangsreëls verbreed word. 'n Volmaak bereikbare SOCKS-ontvanger kan grepe verwerp wat nooit 'n SOCKS-versoek was nie.