Першапачатковыя пункты прызначэння ў празрыстай пералінкоўцы TCP у SOCKS

Міжсеткавы экран можа змяніць, куды трапляе TCP-злучэнне. Але адным гэтым змяненнем ён не можа навучыць зыходны дадатак гаварыць па SOCKS.

Звычайны сервер SOCKS чакае перамоваў з апісаннем запытанага пункта прызначэння. Дадатак, які не ведае пра проксі, замест гэтага адразу дасылае ўласныя байты пратаколу. Перанакіруйце гэтыя байты проста ў слухач SOCKS, і бакі разыйдуцца ў поглядзе на першае паведамленне.

Адсутны кампанент — гэта транслятар

Празрысты кампанент пералінкоўкі TCP у проксі знаходзіцца паміж гэтымі інтэрфейсамі. Ён выяўляе пункт прызначэння, які першапачаткова запытаў дадатак, устанаўлівае адпаведную сесію SOCKS або HTTP CONNECT, а затым перадае даныя дадатка праз атрыманы паток.

На шляху Linux iptables крыніца redsocks атрымлівае захаваны пункт прызначэння з дапамогай SO_ORIGINAL_DST. Іншыя аперацыйныя сістэмы і спосабы перанакіравання выкарыстоўваюць іншыя механізмы. Гэта ўласцівасць перанакіроўвальніка і наладкі сеткі, а не звычайная магчымасць кліента SOCKS.

Звесткі пра першапачатковы пункт прызначэння таксама тлумачаць, чаму перанос правіла перанакіравання з хоста проксі на незвязаны шлюз не заўсёды раўназначны. Працэс, што прымае, патрабуе метаданых, якіх вымагае яго рэжым перахопу. Адрас, перапісаны ў іншым месцы, можа ўжо не даваць гэтых звестак у чаканай форме.

Трымайце межы транслятара яснымі. Працуючае перанакіраванае TCP-злучэнне не даказвае падтрымку адвольнага UDP, ICMP або любога шляху рэзалвера. Пратакол вышэйшага проксі і рэалізацыя транслятара ўсё яшчэ вызначаюць падтрыманыя аперацыі.

Калі наладка збаўляе адразу пасля злучэння, праверце мяжу пратаколу, перш чым пашыраць правілы доступу. Цалкам дасягальны слухач SOCKS можа адхіліць байты, якія ніколі не былі запытам SOCKS.