En firewall kan ændre, hvor en TCP-forbindelse lander. Alene med den ændring kan den ikke lære den oprindelige applikation at tale SOCKS.

En almindelig SOCKS-server forventer en forhandling, der beskriver den ønskede destination. En applikation, der ikke kender proxyen, sender i stedet straks sine egne protokolbyte. Omdiriger de byte direkte til en SOCKS-lytter, og de to sider er uenige om den første meddelelse.

Den manglende komponent er en oversætter

En transparent TCP-til-proxy-komponent sidder mellem disse grænseflader. Den finder den destination, applikationen oprindeligt bad om, opretter den passende SOCKS- eller HTTP CONNECT-session og videresender derefter applikationsdata over den resulterende strøm.

På sin Linux iptables-vej henter redsocks-kilden den bevarede destination ved hjælp af SO_ORIGINAL_DST. Andre operativsystemer og omdirigeringsmetoder bruger andre mekanismer. Dette er en egenskab ved omdirigereren og netværksopsætningen, ikke en almindelig SOCKS-klientfunktion.

Oplysninger om den oprindelige destination forklarer også, hvorfor det ikke altid er ensbetydende at flytte en omdirigeringsregel fra proxyværten til en ikke-tilknyttet gateway. Den modtagende proces har brug for de metadata, som dens aflytningsmåde kræver. En adresse, der er skrevet om andre steder, giver måske ikke længere den oplysning i den forventede form.

Hold oversætterens omfang klart. En fungerende omdirigeret TCP-forbindelse beviser ikke støtte til vilkårlig UDP, ICMP eller enhver resolver-vej. Den opstrøms proxyprotokol og oversætterens implementering definerer stadig de understøttede handlinger.

Når en opsætning fejler umiddelbart efter forbindelsen, skal du kontrollere protokolgænsen, før du udvider adgangsreglerne. En fuldt ud tilgængelig SOCKS-lytter kan afvise byte, der aldrig var en SOCKS-anmodning.

Relaterede artikler