Cyrchfannau gwreiddiol wrth anfon TCP i SOCKS yn dryloyw

Gall mur rhag tân newid i ble y mae cysylltiad TCP yn glanio. Ni all, drwy'r newid hwnnw yn unig, ddysgu i'r cymhwysiad gwreiddiol siarad SOCKS.

Mae gweinydd SOCKS cyffredin yn disgwyl trafodaeth sy'n disgrifio'r gyrchfan a ofynnwyd amdani. Mae cymhwysiad nad yw'n gwybod am y dirprwy yn anfon ei ffeiliau protocol ei hun ar unwaith yn lle hynny. Ailgyfeiriwch y beitiau hynny'n syth at wrandawr SOCKS a bydd y ddwy ochr yn anghytuno ynghylch y neges gyntaf.

Y gydran sydd ar goll yw cyfieithydd

Mae cydran dryloyw TCP-i-ddirprwy yn eistedd rhwng y rhyngwynebau hynny. Mae'n darganfod y gyrchfan y gofynnodd y cymhwysiad amdani'n wreiddiol, yn sefydlu'r sesiwn SOCKS neu HTTP CONNECT briodol, ac yna'n trosglwyddo data'r cymhwysiad dros y ffrwd a ganlyniadodd.

Ar ei lwybr Linux iptables, mae ffynhonnell redsocks yn adfer y gyrchfan a gadwyd drwy SO_ORIGINAL_DST. Mae systemau gweithredu eraill a dulliau ailgyfeirio eraill yn defnyddio mecanweithiau gwahanol. Mae hyn yn briodwedd o'r ailgyfeirydd a'r trefniant rhwydwaith, nid yn nodwedd cleient SOCKS cyffredin.

Mae gwybodaeth am y gyrchfan wreiddiol hefyd yn esbonio pam nad yw symud rheol ailgyfeirio o westeiwr y dirprwy i borth arall heb gysylltiad bob amser yn gyfwerth. Mae'r broses sy'n derbyn angen y metadata y mae ei dull rhyng-gipio yn ei gwneud yn ofynnol. Efallai na fydd cyfeiriad a ailysgrifennwyd yn rhywle arall yn darparu'r wybodaeth honno yn y ffurf a ddisgwylir.

Cadwch gwmpas y cyfieithydd yn glir. Nid yw cysylltiad TCP ailgyfeiriedig sy'n gweithio yn profi cefnogaeth ar gyfer UDP mympwyol, ICMP, nac ar gyfer pob llwybr datryswr. Mae protocol y dirprwy uwchradd a gweithrediad y cyfieithydd yn dal i ddiffinio'r gweithrediadau a gefnogir.

Pan fydd gosodiad yn methu'n syth ar ôl cysylltu, gwiriwch ffin y protocol cyn ehangu rheolau mynediad. Gall gwrandawr SOCKS y gellir ei gyrraedd yn berffaith wrthod beitiau nad oeddent erioed yn gais SOCKS.