Перасылка TCP да фіксаванага пункту прызначэння з дапамогай Windows portproxy
Правіла portproxy накіроўвае слухача да фіксаванага пункту прызначэння. Яно не дадае ўзгадненне SOCKS або HTTP CONNECT, якога чакаюць кліенты з падтрымкай проксі.
Правіла portproxy у Windows перасылае TCP да аднаго наладжанага пункту прызначэння. Яно не ўзгадняе запыт HTTP-проксі браўзера або запыт пункту прызначэння SOCKS.
| Служба | Хто выбірае пункт прызначэння? |
|---|---|
| Фіксаваны рэтранслятар TCP | Налады перасылкі слухача. |
| Проксі SOCKS5 | Запыт кліента ў межах палітыкі сервера. |
| Прамы HTTP-проксі | Запыт HTTP-проксі, уключаючы CONNECT для звычайнага тунэлявання HTTPS. |
Агледзіце існуючы рэтранслятар з дапамогай netsh interface portproxy show all. Параўнайце яго наладжаны бэкэнд з пратаколам, які адпраўляе ваш кліент. даведка па netsh апісвае адрасы і порты слухача і пункту прызначэння; прыняцце TCP не ўстанаўлівае рукапоціск HTTP або SOCKS.
Узгадненне SOCKS, адпраўленае звычайнаму рэтранслятару, проста дасягае гэтага фіксаванага бэкэнда. Яно не можа прымусіць службу без SOCKS зразумець запыт або выбраць новую мэту.
Рэтранслятар перад сапраўдным проксі — гэта іншае. Вышэйшы проксі ўсё яшчэ ўзгадняе пункты прызначэння і аўтэнтыфікацыю; рэтранслятар пераносіць злучэнне да яго. Рэтранслятар, адкрыты ў сетку, можа пашырыць доступ да гэтага бэкэнда, таму трымайце мяжу доступу слухача свядомай.
Выбірайце службу з падтрымкай пратаколу, калі патрэбен агульны выхад HTTP або SOCKS. Перанакіраваны порт — гэта толькі частка такога шляху.