maybeonly 最近的时间轴更新 maybeonly 最近的时间轴更新 |
maybeonlyV2EX 第 193338 号会员，加入于 2016-09-25 08:10:24 +08:00今日活跃度排名 4938 |
| 跟风贴自家软路由实现
3 宽带症候群 • maybeonly • 20 天前 • 最后回复来自 kenywei001
|
53 |
maybeonly 最近回复了
5 天前 回复了 basncy 创建的主题 › 宽带症候群 › 小学生的旁路由才需要动光猫配置 |
arp 这东西老，但是大多数仍然好用。
但是，用 arp 欺骗，特别破坏网络，强烈不建议使用。
v6 使用 ndp （上面写了，ref: https://zh.wikipedia.org/wiki/%E9%82%BB%E5%B1%85%E5%8F%91%E7%8E%B0%E5%8D%8F%E8%AE%AE ）
看一下 icmpv6 的 type133~137
也不复杂，有 ndppd ，或者自己看着包结构搓也容易
以及 我选择自己搓主路由
但是，用 arp 欺骗，特别破坏网络，强烈不建议使用。
v6 使用 ndp （上面写了，ref: https://zh.wikipedia.org/wiki/%E9%82%BB%E5%B1%85%E5%8F%91%E7%8E%B0%E5%8D%8F%E8%AE%AE ）
看一下 icmpv6 的 type133~137
也不复杂，有 ndppd ，或者自己看着包结构搓也容易
以及 我选择自己搓主路由
5 天前 回复了 basncy 创建的主题 › 宽带症候群 › 小学生的旁路由才需要动光猫配置 |
这个标题确实很能激发讨论的欲望
不过，除了 arp ，至少还有 ndp 要处理吧……什么，不管 v6 ？
就算不管 v6 ，那 arp 欺骗也不是每次都能成功的，如果 arp 过期没成功，连接不就尴尬了？
再有就是关闭设备的时候了，网关没了，其他设备断网重新学习网关……
不过，除了 arp ，至少还有 ndp 要处理吧……什么，不管 v6 ？
就算不管 v6 ，那 arp 欺骗也不是每次都能成功的，如果 arp 过期没成功，连接不就尴尬了？
再有就是关闭设备的时候了，网关没了，其他设备断网重新学习网关……
5 天前 回复了 presoul 创建的主题 › 宽带症候群 › 四川移动 cloudflare |
这不挺好的嘛
快测测性能怎么样
只要你不怕他
他就是免费的隧道
grpc/wss 走起来
快测测性能怎么样
只要你不怕他
他就是免费的隧道
grpc/wss 走起来
5 天前 回复了 presoul 创建的主题 › 宽带症候群 › 四川移动 cloudflare |
cf 的话 curl 一下不就知道了吗
如果他 nat 的话连他出口 ip 也一起看光光
curl -v https://ip.sb/cdn-cgi/trace --resolve ip.sb:443:104.18.4.101
如果他 nat 的话连他出口 ip 也一起看光光
curl -v https://ip.sb/cdn-cgi/trace --resolve ip.sb:443:104.18.4.101
5 天前 回复了 KirbySD 创建的主题 › 宽带症候群 › 除 IP 黑洞外，「只代理 TLS 握手，在 TLS 会话失效之前直连」是否有可行性 |
quic 实际上也不一定可行，看服务端配置/实现
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密
p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密
p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器
7 天前 回复了 CirnoSalt 创建的主题 › 宽带症候群 › 坐标 0471 联通宽带疑似开始限制连接数 |
问题是，如何确定是“不针对 pcdn 而是把所有用户一刀切”呢
20 天前 回复了 lanthora 创建的主题 › 宽带症候群 › WireGuard 跨国组网失败后,一个新工具的诞生 |
20 天前 回复了 lanthora 创建的主题 › 宽带症候群 › WireGuard 跨国组网失败后,一个新工具的诞生 |
@lanthora @Damn
> 在某些情况下 WireGuard 会断线,只有重启客户端才能解决
这是因为防火墙或者 nat 造成的。因为 wireguard 不会改变 udp 的源端口。
同时目的 ip 和端口也不会变，这就会导致，对应的失效 nat 表项一直不会超时。
对于自家路由器 ip 变化的情况，可以在路由器更换 ip 的时候清理出口的 conntrack 表得到解决。
但是这也是权衡利弊的结果。只有依赖这样的固定端口 udp ，才能组成“网状网络”而非“一个一个的连接”
其实跨国的话试试看 wireguard over ipv6 吧，感觉根本没人管啊。
作为后备方案，可以考虑 openvpn tcp over xray/hysteria ，不要嫌弃 openvpn 重，人家原生支持 tcp ，而且组网功能完善。
> 在某些情况下 WireGuard 会断线,只有重启客户端才能解决
这是因为防火墙或者 nat 造成的。因为 wireguard 不会改变 udp 的源端口。
同时目的 ip 和端口也不会变，这就会导致，对应的失效 nat 表项一直不会超时。
对于自家路由器 ip 变化的情况，可以在路由器更换 ip 的时候清理出口的 conntrack 表得到解决。
但是这也是权衡利弊的结果。只有依赖这样的固定端口 udp ，才能组成“网状网络”而非“一个一个的连接”
其实跨国的话试试看 wireguard over ipv6 吧，感觉根本没人管啊。
作为后备方案，可以考虑 openvpn tcp over xray/hysteria ，不要嫌弃 openvpn 重，人家原生支持 tcp ，而且组网功能完善。
22 天前 回复了 maybeonly 创建的主题 › 宽带症候群 › 跟风贴自家软路由实现 |
@povsister
简要流程：
DNS on query -> 匹配隧道？ -> YES: 丢给对应的隧道 / NO: 丢回系统递归
DNS on reply -> 匹配隧道？ -> NO: 直接返回
... -> YES: 必要时查 ipv4/v6 映射表 -> 记录 DNS 结果地址、DNS 请求的源地址（ edns 或者源 IP ），设置 TTL （比如不超过 5min ） -> 设置路由规则（源，目的，超时时间，隧道 ID 。其中超时=DNS 超时+允许的宽限时间） -> 返回记录
on PACKET -> 匹配路由规则（超时的这里就匹不到了）？ -> YES: 修改目的 MAC 为隧道对应的 MAC / NO: 修改目的 MAC 为 OWGW 的 MAC -> rawsocket 发出
系统的路由表实现源*目的匹配各种不方便，更别说超时了。这也是自己搓二进制的主要原因。
简要流程：
DNS on query -> 匹配隧道？ -> YES: 丢给对应的隧道 / NO: 丢回系统递归
DNS on reply -> 匹配隧道？ -> NO: 直接返回
... -> YES: 必要时查 ipv4/v6 映射表 -> 记录 DNS 结果地址、DNS 请求的源地址（ edns 或者源 IP ），设置 TTL （比如不超过 5min ） -> 设置路由规则（源，目的，超时时间，隧道 ID 。其中超时=DNS 超时+允许的宽限时间） -> 返回记录
on PACKET -> 匹配路由规则（超时的这里就匹不到了）？ -> YES: 修改目的 MAC 为隧道对应的 MAC / NO: 修改目的 MAC 为 OWGW 的 MAC -> rawsocket 发出
系统的路由表实现源*目的匹配各种不方便，更别说超时了。这也是自己搓二进制的主要原因。
Select Language