Jatorrizko helmugak TCPtik SOCKSera birbidaltze gardenan

Suhesi batek alda dezake TCP konexio bat non amaitzen den. Baina aldaketa horrekin soilik ezin dio jatorrizko aplikazioari SOCKS hitz egiten irakatsi.

SOCKS zerbitzari arrunt batek eskatutako helmuga deskribatzen duen negoziazioa espero du. Proxyaren berri ez duen aplikazio batek, ordea, bere protokolo-byteak berehala bidaltzen ditu. Bideratu byte horiek zuzenean SOCKS entzule batera eta bi aldeak ez dira ados jarriko lehen mezuan.

Falta den osagaia itzultzailea da

TCPtik proxyrako osagai garden bat interfaze horien artean dago. Aplikazioak hasieran eskatu zuen helmuga aurkitzen du, SOCKS edo HTTP CONNECT saio egokia ezartzen du, eta ondoren aplikazioaren datuak sortutako fluxutik bidaltzen ditu.

Bere Linux iptables bidean, redsocks iturburuak gordetako helmuga eskuratzen du SO_ORIGINAL_DST erabiliz. Beste sistema eragile eta birbideratze metodo batzuek mekanismo desberdinak erabiltzen dituzte. Hau birbideratzailearen eta sare-konfigurazioaren ezaugarria da, ez SOCKS bezero arrunt baten funtzioa.

Jatorrizko helmugaren informazioak ere azaltzen du zergatik ez den beti baliokidea birbideratze-arau bat proxy ostalaritik aparteko atebide batera eramatea. Harten duen prozesuak bere atzemate-moduak eskatzen dituen metadatuak behar ditu. Beste nonbait berridatzitako helbide batek agian ez du informazio hori espero den forman ematen.

Eduki itzultzailearen irismena argi. Funtzionatzen duen birbideratutako TCP konexioak ez du frogatzen UDP arbitrarioa, ICMP edo ebazte-bide guztiak onartzen direnik. Goiko proxy protokoloak eta itzultzailearen inplementazioak oraindik ere zehazten dituzte onartutako eragiketak.

Konfigurazio batek konexioaren ostean berehala huts egiten badu, egiaztatu protokoloaren muga sarbide-arauak zabaldu aurretik. Guztiz irisgarria den SOCKS entzule batek inoiz SOCKS eskaera izan ez diren byteak bazter ditzake.