Opphavlege mål i gjennomsiktig TCP-til-SOCKS-vidaresending
Forklarer kvifor gjennomsiktig TCP-til-SOCKS-vidaresending treng ein omsetjar som gjenopprettar det opphavlege målet før det blir forhandla med proxyen.
Ein brannmur kan endre kvar ein TCP-tilkopling landar. Men berre med den endringa kan han ikkje lære den opphavlege applikasjonen å snakke SOCKS.
Ein vanleg SOCKS-tenar ventar ei forhandling som skildrar målet som er bedt om. Ein applikasjon som ikkje kjenner proxyen, sender i staden straks sine eigne protokollbyte. Omdiriger dei byta rett til ein SOCKS-lyttar, og dei to sidene er usamde om den første meldinga.
Den manglande komponenten er ein omsetjar
Ein gjennomsiktig TCP-til-proxy-komponent sit mellom desse grensesnitta. Han finn målet applikasjonen opphavleg bad om, etablerer den høvelege SOCKS- eller HTTP CONNECT-økta og videresender så applikasjonsdata over straumen som oppstår.
På sin Linux iptables-veg hentar redsocks-kjelda det verna målet ved hjelp av SO_ORIGINAL_DST. Andre operativsystem og omdirigeringsmetodar brukar andre mekanismar. Dette er ein eigenskap ved omdirigeraren og nettoppsettet, ikkje ein vanleg SOCKS-klientfunksjon.
Informasjon om det opphavlege målet forklarar òg kvifor det ikkje alltid er likeverdig å flytte ei omdirigeringsregel frå proxyverten til ein urelatert gateway. Prosessen som tek imot, treng metadataa som avlyttingsmåten hans krev. Ei adresse som er skriven om andre stader, gjev kanskje ikkje lenger den informasjonen i venta form.
Hald omfanget til omsetjaren tydeleg. Ei fungerande omdirigert TCP-tilkopling beviser ikkje støtte for vilkårleg UDP, ICMP eller kvar oppslagsveg. Oppstraums proxyprotokoll og implementasjonen til omsetjaren definerer framleis dei støtta operasjonane.
Når eit oppsett feilar rett etter tilkoplinga, sjekk protokollgrensa før du utvidar tilgangsreglane. Ein fullt ut tilgjengeleg SOCKS-lyttar kan avvise byte som aldri var ei SOCKS-førespurnad.