正向socks代理实现多路复用 about iox

[EddieIvan01]

首先，目前的正向代理是可以加密的（iox proxy -l的参数支持加*），但需要本地用iox fwd起一个agent

你的需求可以通过上述类似的方法实现多路复用，但这样非多路复用的正向代理就没法用了（类似反向代理仅支持多路复用，但正向代理是不需要双端配合的）

新增子命令可行，但容易增加复杂度和造成参数上的混乱，也不够统一

---

初步构想，通过提供一个新的flag（例如at）来表示开启socket的多路复用，做到所有模式下的统一，比如

iox proxy -l @*0.0.0.0:9999 -k ff 
iox fwd -l 1080 -r @*1.1.1.1:9999 -k ff 

[L-codes]

结合 pwd 让 socks5 加密这个可以！

随便想提提 * 标记作为加密这个设计不太好，因为在 zsh 中会当做是通配符，则需要添加单引号 '*0.0.0.0:9999' 并且还有 *:9999的歧义问题
换成字母形等表示会否更加好？如 m = Multiplexing, s = secret 则加密复用端 ms:0.0.0.0:9999

[EddieIvan01]

方案二有些混乱，比如正向代理iox proxy:1080 iox:1.1.1.1:9999 只是把本地流量处理后转发到远端，和上层协议是无关的。把加密和多路复用看作新协议有违直觉，而应该视作iox构建了一个传输层信道，这样对每一个socket都可以通过flag指定信道特性，并且特性可以自由组合（或扩展新特性，比如压缩、使用不同协议传输）

方案一不需要自动识别的，完全由用户指定的flag决定

至于扩展其他协议的通信信道，icmp/dns可行，但因为是包协议，项目逻辑需要大改，并且需要自实现ARQ。kcp虽然是现成的ARQ协议，但由于它会发送大量冗余流量提高速度，并不适合渗透中使用

[EddieIvan01]

确实星号属于设计失误，最初没有考虑到bash的解析。也导致了与Go接受:PORT 参数结合而产生的歧义

用字母表示确实是更优的设计，感谢

[L-codes]

思考了一下，换成字母标记也不够好，建议重新设计UI逻辑，因为加密和多路复用功能是 iox 私有的通讯协议，即 iox 两端连接的协议才支持加密和多路复用，并且在 iox 需要两端连接时，由于多路复用的优势明显应默认开启，那有两个方案：

方案一 （即目前上面讨论的方案） iox 自动识别连接端是否 iox，自动启用多路复用，检测是否有 -k 参数存在则自动对 iox 间尝试进行加密通讯
但是存在 正反向 socks 不统一的问题，(并且反向 socks 还需要按顺序。。。我老是记错)，如：

反向 socks 使用
    ./iox proxy -l @*0.0.0.0:9999 -k ff 
    ./iox fwd -l 1080 -r @*1.1.1.1:9999 -k ff 
正向 socks 使用
    ./iox proxy -r 1.1.1.1:9999
    ./iox proxy -l 9999 -l 1080       // notice, the two port are in order

方案二 类似 socat 一样，为连接端标记类型，这样所见即所得，并且不区分两端参数左右顺序

两端的链接格式，类似 socat
<mark>:[ip:]<port>
mark:
    tcp       -- TCP 连接（协议命名，也方便后续如果有 udp 协议等)
    tcp-l     -- TCP 监听
    proxy     -- proxy 监听 (因为 proxy 暂时只有监听，后续要是考虑支持 socks 连接转发隧道，则可以恢复 proxy-l 的命名； 如果还考虑更多的 socks4a 等协议，建议 proxy 改名为 socks5）
    iox       -- 这里说的是 iox 自己的通讯协议连接，即 `-k` 可选的加密并默认的就是多路复用协议（也可以通过添加参数禁用多路复用)，但是这是 iox 自己的协议，命名暂未想到好的这里称叫 iox...
    iox-l     -- iox 私自可加密的多路复用协议监听

TCP 端口转发 (没有过多的变化)
./iox fwd -l 8888 -l 9999                  => ./iox tcp-l:8888 tcp-l:9999
./iox fwd -l 8888 -r 1.1.1.1:9999          => ./iox tcp-l:8888 tcp:1.1.1.1:9999
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999  => ./iox tcp:1.1.1.1:8888 tcp:1.1.1.1:9999

本地 proxy (没有过多的变化)
server: ./iox proxy -l 1080     =>  ./iox proxy:1080

反向 proxy (不会搞混 socks 是连 9999 还是 1080，`proxy:1080` 已经标记了)
server:  ./iox proxy -l 9999 -l 1080  =>  ./iox iox-l:9999 proxy:1080
client: ./iox proxy -r 1.1.1.1:9999   =>  ./iox iox:1.1.1.1:9999

正向 proxy (其实与反向是相对的，仅 iox 协议两端连接方向发生变化，也清晰知道 socks 是 cilent 端的 1080)
server: ./iox proxy -l 0.0.0.0:9999        =>  ./iox iox-l:9999
client: ./iox fwd -l 1080 -r 1.1.1.1:9999  =>  ./iox proxy:1080 iox:1.1.1.1:9999

补充说明：
-k 参数仅对 iox iox-l 端协议生效
如有必要后续可以补充一个参数，让 iox 自己的协议，关闭多路复用

对比之下，方案一要实现自动检测才能省去标记加密和多路复用的麻烦，并且正反向代理的不统一，两端参数还需要有序要求，暴露出很多设计问题，而方案二简单理解就是给 socat 添加了，两个协议 proxy 和自己的可加密多路复用协议 iox，也同样方便后续的协议支持扩展，建议重新设计使用第二个方案，使用逻辑更加简单，扩展性也更加好~

[L-codes]

针对上面的方案二，加一个补充

因为 iox 协议是计划作为 iox 多端间通讯的协议，目前是基于 tcp 的，而我看该项目 github 的标签中包含 pentest 的定位，应当考虑，后续 iox 间通讯要有 kcp(UDP的RRQ协议)、icmp 等支持，在渗透中才能发挥出更大的作用，所以 iox 协议，可能改成 itcp 表示基于 tcp 的 iox 协议，则 kcp icmp 等可以为 ikcp iicmp等。

但如果考虑编译后文件大小的问题，也可以将基于 tcp kcp icmp 等各个分开编译版本，这样 iox 协议的命名任可以直接使用，而无需 ikcp itcp 等不同命名

[L-codes]

”方案一不需要自动识别的，完全由用户指定的flag决定“ 我是觉得不加flag进行使用的设计，则需要自动识别

方案二 没明白混乱的点，逻辑确实是 上面拟作的 iox协议 只作为连接两端，实现 proxy的转发，逻辑应该是没错的

正向 proxy (其实与反向是相对的，仅 iox 协议两端连接方向发生变化，也清晰知道 socks 是 cilent 端的 1080)
server: ./iox proxy -l 0.0.0.0:9999        =>  ./iox iox-l:9999
client: ./iox fwd -l 1080 -r 1.1.1.1:9999  =>  ./iox proxy:1080 iox:1.1.1.1:9999

正向代理中 ./iox iox-l:9999 这一端，只有一个参数，没有进行转发等，所以 另一端的 proxy:1080 收集socket 进行转发到 iox-l:9999 这一端服务器上进行连接 

kcp 的 ARQ 发送大量冗余提高速度这个确实不知道，感谢提醒~

另外，如采用方案二确实项目逻辑需要大改，方便的话可否发送 wechat 账号给我邮箱(bC1jb2Rlc0BxcS5jb20K)，方便交流?

[EddieIvan01]

你感受一下，正向代理只做单端

server: iox proxy -l m:0.0.0.0:9999
client: iox fwd -l :1080 -r m:1.1.1.1:9999

想了想，不同协议传输信道也不需要大改，为ARQ协议实现Ctx.Read /Write 即可