Opprinnelige destinasjoner i gjennomsiktig TCP-til-SOCKS-videreformidling
Forklarer hvorfor gjennomsiktig TCP-til-SOCKS-videreformidling trenger en oversetter som gjenoppretter den opprinnelige destinasjonen før den forhandler med proxyen.
En brannmur kan endre hvor en TCP-tilkobling lander. Alene med den endringen kan den ikke lære den opprinnelige applikasjonen å snakke SOCKS.
En vanlig SOCKS-server forventer en forhandling som beskriver den ønskede destinasjonen. En applikasjon som ikke kjenner proxyen, sender i stedet umiddelbart sine egne protokollbyte. Omdiriger disse bytene rett til en SOCKS-lytter, og de to sidene er uenige om den første meldingen.
Den manglende komponenten er en oversetter
En gjennomsiktig TCP-til-proxy-komponent sitter mellom disse grensesnittene. Den finner destinasjonen applikasjonen opprinnelig ba om, etablerer den passende SOCKS- eller HTTP CONNECT-økten og videresender deretter applikasjonsdata over strømmen som oppstår.
På sin Linux iptables-rute henter redsocks-kilden den bevarede destinasjonen ved hjelp av SO_ORIGINAL_DST. Andre operativsystemer og omdirigeringsmetoder bruker andre mekanismer. Dette er en egenskap ved omdirigereren og nettverksoppsettet, ikke en vanlig SOCKS-klientfunksjon.
Informasjon om den opprinnelige destinasjonen forklarer også hvorfor det ikke alltid er likeverdig å flytte en omdirigeringsregel fra proxyverten til en urelatert gateway. Den mottakende prosessen trenger metadataene som avlyttingsmåten dens krever. En adresse som er skrevet om andre steder, gir kanskje ikke lenger den informasjonen i forventet form.
Hold omfanget til oversetteren tydelig. En fungerende omdirigert TCP-tilkobling beviser ikke støtte for vilkårlig UDP, ICMP eller enhver oppslagsvei. Oppstrøms proxyprotokoll og oversetterens implementasjon definerer fortsatt de støttede operasjonene.
Når et oppsett feiler rett etter tilkoblingen, sjekk protokollgrensen før du utvider tilgangsreglene. En fullt ut tilgjengelig SOCKS-lytter kan avvise byte som aldri var en SOCKS-forespørsel.