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