SOCKS5 - 连接认证
SOCKS5 - Connection authentication
我正在尝试根据 RFC1928 实施反向 SOCKS5。我有一个中继服务器，它被动地等待来自充当代理的 SOCKS5 客户端和想要使用隧道的客户端的连接。
图例
服务器 (10.211.55.6) = 中继 = PC 1 (send/recv)
Client_1 (10.211.55.10) = 代理（运行 在我网络中的另一台 PC 上）
Client_2 (10.211.55.8) = Tunneller（从傲游浏览器连接（因为它允许 SOCKS5 身份验证））
执行流程
- Client_1 连接到端口 9444 上的服务器
- 服务器找到一个未使用的端口并绑定到它（假设端口 13451 已打开）
- Client_2 连接到端口 13451 上的服务器
- 服务器接受连接，现在中继 Client_1 和 Client_2
之间的流量
- Client_2 将 SOCKS5 协议（根据 RFC1928）请求发送到 Client_1，通过服务器
中继
- Client_1 进行身份验证并获取到
https://dnsleaktest.com 的 CONNECT 命令并发回 status_ok 响应
- 收到网页包，加载网页
问题
- Client_2 想连接到另一个网页（以
https://packetstormsecurity.com 为例）。
问题
Client_1 只从 Client_2 收到一些数据包，例如 \x17\x3\x3 或 \x17\x3\x3\x1 （这些字节代表什么？）。 Client_1是否需要重新通过SOCKS5认证，或者如何处理对新网页的请求？
旁注
A) 一段时间后，Client_2 向 Client_1 returns ERR_TIMED_OUT 请求的页面在浏览器中，因为 Client_2 没有得到任何回应。但是，如果它期待响应，那么它还假设我知道如何解析它发送的字节，但我不知道它们是什么，因为我在 RFC1928 文档中没有看到它们。
Client_1 only receives a few packets from Client_2 such as \x17\x3\x3 or \x17\x3\x3\x1 (what do these bytes represent?).
Client_2 正在请求到 HTTPS 主机的隧道。在建立到 HTTPS 服务器的 SOCKS 隧道之后，您看到的是 Client_2 和 HTTPS 服务器之间的 TLS 1.2 个数据包：
\x17 = content type (#23, application data)
\x03 = major version 3
\x03 = minor version 3
\x01 = fragment length (1 byte)
...
Does Client_1 have to go through the SOCKS5 authentication again
一旦建立了 SOCKS 隧道，通过该隧道传输的所有内容都是 application-defined 数据。因此，SOCKS 客户端无法通过现有的 TCP 连接发送新的 SOCKS 命令。这意味着 Client_2 必须创建一个新的 TCP 连接到您的中继服务器（因此到 Client_1），以便请求一个新的 SOCKS 隧道到不同的主机，这涉及一个新的 SOCKS 身份验证握手，是的（即使不涉及 SOCKS，Client_2 也必须与新主机建立新的 TCP 连接）。
or how would it process the request to the new webpage?
Client_1 必须等待接受来自 Client_2（或任何其他客户端）的新 TCP 连接，然后才能处理对新 SOCKS 隧道的请求。
After a while, the page that Client_2 requested from Client_1 returns ERR_TIMED_OUT in the browser, since Client_2 didn't get any response.
那么 HTTPS 服务器没有响应 Client_2 的 HTTPS 请求，或者更可能的是 Client_1 在处理 SOCKS 隧道时存在逻辑错误，没有中继 HTTPS 服务器的请求对 Client_2.
的响应数据
But if its expecting a response, then its also assuming that I know how to parse the bytes that it sends, but I don't know what they are as I haven't seen them in the RFC1928 documentation.
一旦 Client_1 建立了 SOCKS 隧道，它就不会解析通过该隧道传输的任何内容（除非您协商的 SOCKS 身份验证方案需要封装传输的数据）。通过 SOCKS 隧道传输的数据是 application-defined，因此只有隧道两端的客户端和目标服务器知道数据到底是什么。 Client_1 必须中继 as-is（如果需要处理封装）双向接收的任何原始数据（就像您的中继服务器所做的那样）。
我正在尝试根据 RFC1928 实施反向 SOCKS5。我有一个中继服务器，它被动地等待来自充当代理的 SOCKS5 客户端和想要使用隧道的客户端的连接。
图例
服务器 (10.211.55.6) = 中继 = PC 1 (send/recv)
Client_1 (10.211.55.10) = 代理（运行 在我网络中的另一台 PC 上）
Client_2 (10.211.55.8) = Tunneller（从傲游浏览器连接（因为它允许 SOCKS5 身份验证））
执行流程
- Client_1 连接到端口 9444 上的服务器
- 服务器找到一个未使用的端口并绑定到它（假设端口 13451 已打开）
- Client_2 连接到端口 13451 上的服务器
- 服务器接受连接，现在中继 Client_1 和 Client_2 之间的流量
- Client_2 将 SOCKS5 协议（根据 RFC1928）请求发送到 Client_1，通过服务器 中继
- Client_1 进行身份验证并获取到
https://dnsleaktest.com的 CONNECT 命令并发回status_ok响应 - 收到网页包，加载网页
问题
- Client_2 想连接到另一个网页（以
https://packetstormsecurity.com为例）。
问题
Client_1 只从 Client_2 收到一些数据包，例如 \x17\x3\x3 或 \x17\x3\x3\x1 （这些字节代表什么？）。 Client_1是否需要重新通过SOCKS5认证，或者如何处理对新网页的请求？
旁注
A) 一段时间后，Client_2 向 Client_1 returns ERR_TIMED_OUT 请求的页面在浏览器中，因为 Client_2 没有得到任何回应。但是，如果它期待响应，那么它还假设我知道如何解析它发送的字节，但我不知道它们是什么，因为我在 RFC1928 文档中没有看到它们。
Client_1 only receives a few packets from Client_2 such as \x17\x3\x3 or \x17\x3\x3\x1 (what do these bytes represent?).
Client_2 正在请求到 HTTPS 主机的隧道。在建立到 HTTPS 服务器的 SOCKS 隧道之后，您看到的是 Client_2 和 HTTPS 服务器之间的 TLS 1.2 个数据包：
\x17 = content type (#23, application data) \x03 = major version 3 \x03 = minor version 3 \x01 = fragment length (1 byte) ...
Does Client_1 have to go through the SOCKS5 authentication again
一旦建立了 SOCKS 隧道，通过该隧道传输的所有内容都是 application-defined 数据。因此，SOCKS 客户端无法通过现有的 TCP 连接发送新的 SOCKS 命令。这意味着 Client_2 必须创建一个新的 TCP 连接到您的中继服务器（因此到 Client_1），以便请求一个新的 SOCKS 隧道到不同的主机，这涉及一个新的 SOCKS 身份验证握手，是的（即使不涉及 SOCKS，Client_2 也必须与新主机建立新的 TCP 连接）。
or how would it process the request to the new webpage?
Client_1 必须等待接受来自 Client_2（或任何其他客户端）的新 TCP 连接，然后才能处理对新 SOCKS 隧道的请求。
After a while, the page that Client_2 requested from Client_1 returns ERR_TIMED_OUT in the browser, since Client_2 didn't get any response.
那么 HTTPS 服务器没有响应 Client_2 的 HTTPS 请求，或者更可能的是 Client_1 在处理 SOCKS 隧道时存在逻辑错误，没有中继 HTTPS 服务器的请求对 Client_2.
的响应数据But if its expecting a response, then its also assuming that I know how to parse the bytes that it sends, but I don't know what they are as I haven't seen them in the RFC1928 documentation.
一旦 Client_1 建立了 SOCKS 隧道，它就不会解析通过该隧道传输的任何内容（除非您协商的 SOCKS 身份验证方案需要封装传输的数据）。通过 SOCKS 隧道传输的数据是 application-defined，因此只有隧道两端的客户端和目标服务器知道数据到底是什么。 Client_1 必须中继 as-is（如果需要处理封装）双向接收的任何原始数据（就像您的中继服务器所做的那样）。