Pag-relay ng TCP patungo sa fixed na destinasyon gamit ang portproxy ng Windows
Ang portproxy rule ay nagpapasa ng listener sa isang fixed na destinasyon. Hindi nito idinadagdag ang SOCKS o HTTP CONNECT na negotiation na inaasahan ng mga client na may alam sa proxy.
Ang portproxy rule ng Windows ay nagre-relay ng TCP patungo sa isang naka-configure na destinasyon. Hindi nito kinakausap ang HTTP proxy request ng browser o ang SOCKS destination request.
| Serbisyo | Sino ang pumipili ng destinasyon? |
|---|---|
| Fixed TCP relay | Ang forwarding configuration ng listener. |
| SOCKS5 proxy | Ang request ng client, sa loob ng patakaran ng server. |
| HTTP forward proxy | Ang HTTP proxy request, kasama ang CONNECT para sa karaniwang HTTPS tunneling. |
Suriin ang umiiral na relay gamit ang netsh interface portproxy show all. Ihambing ang naka-configure na backend nito sa protocol na ipinapadala ng iyong client. Ang reference ng netsh ay naglalarawan ng mga address/port ng listener at destinasyon; ang pagtanggap ng TCP ay hindi nagtatatag ng HTTP o SOCKS handshake.
Ang SOCKS negotiation na ipinadala sa isang ordinaryong relay ay umabot lamang sa fixed na backend na iyon. Hindi nito mapapangyarihang maintindihan ng isang serbisyong hindi SOCKS ang request o pumili ng bagong target.
Ang relay sa harap ng tunay na proxy ay iba. Ang upstream proxy ay nakikipag-negotiate pa rin ng mga destinasyon at authentication; dinadala ng relay ang koneksyon patungo rito. Ang relay na nakalantad sa network ay maaaring magpalawak ng access sa backend na iyon, kaya panatilihing ang hangganan ng access ng listener ay sinasadya.
Pumili ng serbisyong may kakayahan sa protocol kapag ang pangangailangan ay pangkalahatang HTTP o SOCKS exit. Ang forwarded na port ay bahagi lamang ng landas na iyon.