Destinacionet origjinale në përcjelljen transparente TCP-në-SOCKS

Një mur zjarri mund të ndryshojë ku përplaset një lidhje TCP. Por vetëm me atë ndryshim nuk mund t'i mësojë aplikacionit burimor të flasë SOCKS.

Një server i zakonshëm SOCKS pret një negocim që përshkruan destinacionin e kërkuar. Një aplikacion që nuk e njeh proxy-n dërgon menjëherë bajtët e protokollit të vet. Ridrejtoji ato bajtë drejt e në një dëgjues SOCKS dhe të dyja palët nuk do të bien dakord për mesazhin e parë.

Komponenti që mungon është një përkthyes

Një komponent transparent TCP-në-proxy qëndron midis atyre ndërfaqeve. Ai zbulon destinacionin që aplikacioni kërkoi fillimisht, vendos sesionin e duhur SOCKS ose HTTP CONNECT dhe pastaj përcjell të dhënat e aplikacionit mbi rrjedhën e krijuar.

Në rrugën e tij Linux iptables, kodi burimor i redsocks merr destinacionin e ruajtur me anë të SO_ORIGINAL_DST. Sisteme të tjera operative dhe metoda të tjera ridrejtimi përdorin mekanizma të ndryshëm. Kjo është veti e ridrejtuesit dhe e konfigurimit të rrjetit, jo funksion i një klienti të zakonshëm SOCKS.

Informacioni për destinacionin origjinal shpjegon gjithashtu pse zhvendosja e një rregulli ridrejtimi nga hosti i proxy-t në një portë të palidhur nuk është gjithmonë ekuivalente. Procesi marrës ka nevojë për metadatat që kërkon mënyra e tij e përgjimit. Një adresë e rishkruar diku tjetër mund të mos e japë më atë informacion në formën e pritur.

Mbaje të qartë shtrirjen e përkthyesit. Një lidhje TCP e ridrejtuar që funksionon nuk provon mbështetje për UDP arbitrare, ICMP ose çdo rrugë zgjidhësi. Protokolli i proxy-t të sipërm dhe zbatimi i përkthyesit ende përcaktojnë veprimet e mbështetura.

Kur një konfigurim dështon menjëherë pas lidhjes, kontrollo kufirin e protokollit përpara se të zgjerohesh rregullat e aksesit. Një dëgjues SOCKS krejtësisht i arritshëm mund të refuzojë bajtë që nuk kanë qenë kurrë kërkesë SOCKS.