重构以支持更多底层的传输协议

[lanthora]

当前的实现,在不考虑 TUN 设备的情况下,数据只会来源于服务端的 Websocket 和 IPv4 UDP 的 P2P,由于数据来源少,直接把流量的收发都放到了 client 里实现了.

这种情况下想要扩展出更多底层协议,会让 client 变得过于复杂,因此要把部分逻辑迁移到其他模块.

~~暂且把 client 直接处理的流量分为三个部分: TUN, Websocket 和 Peer. 当无法通过 Peer 模块发送时,回退到使用 Websocket 提供的转发功能.~~

client 不直接处理流量,只负责流量在各模块间的转发.

Peer 内部到达指定 Peer 的最短路径,需要在这里面完成对数据的加密伪装或者混淆.对于 UDP 来说,可以使用目前的全加密方案,对于 TCP, 需要考虑全加密过防火墙可能被针对的问题,报文的前端需要有随机的可打印的字符,可以在报文的初始化向量上做手脚,让初始化向量的前两个字节为报文长度,其他字节中一半为随机的可打印字符,另一半为纯随机字符.

[rainpaper-bs]

目前我发现IPv4 UDP P2P模式下好像是明文传输的

[lanthora]

@rainpaper-bs 你是抓的虚拟网卡的包还是物理网卡的包,需要抓物理网卡的包

[rainpaper-bs]

wc，秒回，我看一看

[rainpaper-bs]

在ICMP下是明文的，100.64.0.5是我另一个组网软件的IP，非caddy的ip。caddy直接借助另外一个组网软件的ip链接了

[lanthora]

@rainpaper-bs 首先这东西是 candy, 不是 caddy. 太多人手滑打错了

其次,这不能说明 candy 往外发的 UDP 不是加密的.如果要判断的话,排除掉所有干扰因素,然后抓物理网卡的包. candy 在 P2P 传输的时候是不会发 ICMP 的,目前只会有 UDP.

[rainpaper-bs]

嗯，我建candy websocket server时用了caddy反向代理，然后部署时caddy和candy轮流搞错，整的一塌糊涂🤣 刚刚的问题我看了下，websocket转发时是TLS加密过的 但udp直连加密还未找到证据，我能力不够就不查了，应该是加密的，我希望可以加个这种功能 这样可以直观看到candy是如何转发数据包的，因为tracert无法捕捉，加上这功能有利于调试 我开个新issue？

[lanthora]

@rainpaper-bs 如果只是为了调试，可以看 debug 日志，里面会写流量转发的路径，其实发送方自己也是不确定流量怎么到接收方的，只能知道把流量发给哪个中间客户端能最快送达

[rainpaper-bs]

az，不确定如何到接收方的话这功能没意义了，还是debug日志看看算了