ciaoSora 最近的时间轴更新 ciaoSora 最近的时间轴更新 |
ciaoSoraV2EX 第 479253 号会员，加入于 2020-03-27 10:16:45 +08:00今日活跃度排名 10114 |
| 路由器上 Clash 透明代理时， LAN 内其他设备的 IPv6 地址会被改变？ VPS • ciaoSora • 8 天前 • 最后回复来自 ciaoSora | 4 |
| Clash 的规则是如何做到匹配域名的？ VPS • ciaoSora • 15 天前 • 最后回复来自 ciaoSora | 3 |
| 请问 Seafile 服务端的文件会加密吗？ 服务器 • ciaoSora • 2020-11-24 18:54:35 PM |
| 微信双开/应用分身的最佳解决方案是什么？已 root Android • ciaoSora • 2020-04-10 16:15:50 PM • 最后回复来自 luwies | 2 |
ciaoSora 最近回复了
1 天前 回复了 bex 创建的主题 › 买买买 › 618 准备换手机，求各位大佬推荐一款安卓旗舰机，预算 7k 以内 |
@tgich 我没有 NFC 的需求所以没有关注过。是的三星好像有硬件级别或者反正非常底层的机制，使得 root 之后就有部份功能用不了了。GitHub 上有个 LSPosed 模块叫 [KnoxPatch]( https://github.com/XDABlackMesa123/KnoxPatch) ，root 了之后装这个模块就可以绕过大部份三星的检测机制，但是 Samsung Wallet 和 Samsung Pass （密码管理 app ）还是不能绕过
3 天前 回复了 bex 创建的主题 › 买买买 › 618 准备换手机，求各位大佬推荐一款安卓旗舰机，预算 7k 以内 |
自己买的是三星，买回来刷了港版，使用体验很好。后面由于有抓包需求，也能相对比较方便地 root 了
5 天前 回复了 superus1r 创建的主题 › 宽带症候群 › 深圳联通，目前还有什么办法能申请到公网 v4 吗 |
一样的情况，也是深圳联通，之前打电话请求 v4 ，不给，说只有 v6 ，现在用 v6 用的还行，就是公司网络没有 v6 ，在公司需要手机开热点，然后就可以 ssh 到家里的设备
8 天前 回复了 ciaoSora 创建的主题 › VPS › 路由器上 Clash 透明代理时， LAN 内其他设备的 IPv6 地址会被改变？ |
@heganyuliang 我现在感觉显示路由器的 v6 地址才是正确的行为，「透明代理」这个词里的「透明」应该是仅对 TCP 服务发起端来说的。
就像传统的 IPv4 世界里，你用一个境外的主机建了个机场（代理），然后自己电脑上连接他，那他就是一个不透明的代理，相同点是「都是代理」，既然代理了，那么就会「代替」、「取代」你（ IP 包的 Src IP 会被替换为代理的 IP ），来跟目标服务器通信，然后再把结果发回给你。
不太清楚 www.ip5.me/ipv6 是什么原理…… 感觉跟其他的测试网站似乎不太一样。
然后我现在已经关掉了 ShellClash 的 IPv6 透明代理，直接让所有 v6 的流量直连了，目前运行良好，测试自己的 IP 也都是我的本机 IP 而不是路由器 IP ，境外流量也都顺利地解析为 IPv4 然后走了节点。现在的 ShellClash IPv6 相关配置是：
ipv6 内核支持：已开启； ipv6 透明代理：未开启； ipv6-DNS 解析：已开启； CNIP 绕过内核：未开启
就像传统的 IPv4 世界里，你用一个境外的主机建了个机场（代理），然后自己电脑上连接他，那他就是一个不透明的代理，相同点是「都是代理」，既然代理了，那么就会「代替」、「取代」你（ IP 包的 Src IP 会被替换为代理的 IP ），来跟目标服务器通信，然后再把结果发回给你。
不太清楚 www.ip5.me/ipv6 是什么原理…… 感觉跟其他的测试网站似乎不太一样。
然后我现在已经关掉了 ShellClash 的 IPv6 透明代理，直接让所有 v6 的流量直连了，目前运行良好，测试自己的 IP 也都是我的本机 IP 而不是路由器 IP ，境外流量也都顺利地解析为 IPv4 然后走了节点。现在的 ShellClash IPv6 相关配置是：
ipv6 内核支持：已开启； ipv6 透明代理：未开启； ipv6-DNS 解析：已开启； CNIP 绕过内核：未开启
13 天前 回复了 xiaohusky 创建的主题 › 问与答 › 为什么透明代理中的 REDIRECT 方式仅支持 TCP，不支持 UDP？ |
楼上们说的应该是正解，内核不支持，按照我的理解，原因如下：
TCP 是全双工保证按序交付的传输层协议，所以 Linux 内核支持获取 REDIRECT 之前的 destination 。一个 TCP 连接是以 (Src IP, Src Port, Dst IP, Dst Port) 四元组作为唯一标识的，当真实 destination 发送 TCP 数据包到透明代理时，透明代理知道要把数据返回给 source IP ，因为透明代理内部把 (Src IP, Src Port, Proxy IP, Proxy Port) 和 (Proxy IP, Proxy Client Port, Dst IP, Dst Port) 这两个四元组建立了联系，代理程序清楚地知道，当自己的 Proxy Port 收到来自 source 的数据时，要原封不动地通过第二个 TCP 连接发送给 destination ；当自己的 Proxy Client Port 收到来自 destination 的数据时，要原封不动地通过第一个 TCP 连接发送给 source 。
UDP 几乎就只是在 IP 的基础上加了 Src Port 和 Dst Port ，什么其他功能都没有（不是双工、不保证交付、不一定按序）。假设采取了跟 TCP 一样的原理，当 Proxy Client Port 收到来自 destination 的数据时，能理所当然地直接用 Proxy Port 发回给 source 吗？举个例子，一个人通过 email 投递简历到某公司的 HR 邮箱里（ source 是这个人，destination 是 HR ），HR 读了之后感觉很优秀，认为需要直接让 CEO 跟你对接，于是他把 email 转发给了 CEO （ destination 把数据发给了 thirdparty)，CEO 看完了之后，回了你一封邮件（ thirdparty 发数据给 source ）。假设在 source 前面有一个透明代理，如果他收到的是 HR 的回信那还好，直接理所当然地转回给 source 。但如果是刚刚的情况呢？ HR 没有直接回你，而是让 CEO 回复你，这时透明代理就不知道应该转回给谁了。正因如此，内核就直接不支持获取 REDIRECT 之前的 destination 是什么，因为 UDP 本来是一种不需要建立连接的协议，仅从 UDP 这一层的角度（而不从应用层协议的角度）出发，REDIRECT 之前的 IP 是没意义的。当然应用层的协议可能刚好规定，若 source 给 destination 发数据，那么 destination 必然要跟 source 回复，但是无论应用层怎么规定，UDP 这个传输层的协议是不知道的，也不能做任何乐观假设。
感觉 tproxy 或者其他能代理 UDP 的解决方案，应该就是乐观假设了「 CEO 给你回信」这个场景不会发生？有了这个假设之后，透过其他技术手段（毕竟内核不直接支持）获取到 REDIRECT 之前的 destination 之后，就可以用类似 TCP 的方式把来自 destination 的数据回复给 source 了。
不知道说得对不对，希望大佬能纠正我 =_=
TCP 是全双工保证按序交付的传输层协议，所以 Linux 内核支持获取 REDIRECT 之前的 destination 。一个 TCP 连接是以 (Src IP, Src Port, Dst IP, Dst Port) 四元组作为唯一标识的，当真实 destination 发送 TCP 数据包到透明代理时，透明代理知道要把数据返回给 source IP ，因为透明代理内部把 (Src IP, Src Port, Proxy IP, Proxy Port) 和 (Proxy IP, Proxy Client Port, Dst IP, Dst Port) 这两个四元组建立了联系，代理程序清楚地知道，当自己的 Proxy Port 收到来自 source 的数据时，要原封不动地通过第二个 TCP 连接发送给 destination ；当自己的 Proxy Client Port 收到来自 destination 的数据时，要原封不动地通过第一个 TCP 连接发送给 source 。
UDP 几乎就只是在 IP 的基础上加了 Src Port 和 Dst Port ，什么其他功能都没有（不是双工、不保证交付、不一定按序）。假设采取了跟 TCP 一样的原理，当 Proxy Client Port 收到来自 destination 的数据时，能理所当然地直接用 Proxy Port 发回给 source 吗？举个例子，一个人通过 email 投递简历到某公司的 HR 邮箱里（ source 是这个人，destination 是 HR ），HR 读了之后感觉很优秀，认为需要直接让 CEO 跟你对接，于是他把 email 转发给了 CEO （ destination 把数据发给了 thirdparty)，CEO 看完了之后，回了你一封邮件（ thirdparty 发数据给 source ）。假设在 source 前面有一个透明代理，如果他收到的是 HR 的回信那还好，直接理所当然地转回给 source 。但如果是刚刚的情况呢？ HR 没有直接回你，而是让 CEO 回复你，这时透明代理就不知道应该转回给谁了。正因如此，内核就直接不支持获取 REDIRECT 之前的 destination 是什么，因为 UDP 本来是一种不需要建立连接的协议，仅从 UDP 这一层的角度（而不从应用层协议的角度）出发，REDIRECT 之前的 IP 是没意义的。当然应用层的协议可能刚好规定，若 source 给 destination 发数据，那么 destination 必然要跟 source 回复，但是无论应用层怎么规定，UDP 这个传输层的协议是不知道的，也不能做任何乐观假设。
感觉 tproxy 或者其他能代理 UDP 的解决方案，应该就是乐观假设了「 CEO 给你回信」这个场景不会发生？有了这个假设之后，透过其他技术手段（毕竟内核不直接支持）获取到 REDIRECT 之前的 destination 之后，就可以用类似 TCP 的方式把来自 destination 的数据回复给 source 了。
不知道说得对不对，希望大佬能纠正我 =_=
14 天前 回复了 ciaoSora 创建的主题 › VPS › 路由器上 Clash 透明代理时， LAN 内其他设备的 IPv6 地址会被改变？ |
@xclrr 谢谢大佬！`dig` 了一下 test-ipv6.com , 确实没有 v6 地址，而 www.ip5.me 是有 v6 地址的。但是有点没理解跟 NAT 有什么关系，请问下「过了 NAT 」是什么意思呀？ NAT 不是仅仅是个 IPv4 的概念吗？而且，https://ipv6.test-ipv6.com 是个纯 v6 网站，我访问这个网站时，显示我的 v6 地址仍然是 `RouterIP`……
14 天前 回复了 basncy 创建的主题 › 微软 › 劝大家不要用微软的邮箱, 会丢信且无提示. |
之前在微软工作过，公司发的邮件有时候都会进 spam ，作为个人完全不敢用
15 天前 回复了 ciaoSora 创建的主题 › VPS › Clash 的规则是如何做到匹配域名的？ |
@topqrh 谢谢，看了一下，现在理解了，感恩🙏
Select Language