maybeonly 最近的时间轴更新 maybeonly 最近的时间轴更新 ONLINE |
maybeonlyV2EX 第 193338 号会员，加入于 2016-09-25 08:10:24 +08:00今日活跃度排名 641 |
| 跟风贴自家软路由实现
1 宽带症候群 • maybeonly • 14 天前 • 最后回复来自 kenywei001
|
53 |
maybeonly 最近回复了
1 小时 24 分钟前 回复了 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
1 小时 25 分钟前 回复了 KirbySD 创建的主题 › 宽带症候群 › 除 IP 黑洞外，「只代理 TLS 握手，在 TLS 会话失效之前直连」是否有可行性 |
quic 实际上也不一定可行，看服务端配置/实现
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密
p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器
不过，您都 quic 了，目前是没有 sni 阻断的
（ quic 的 sni 是加密的，虽然第三方可以做到直接解密
p.s. 很多时候简单地分片就可以过无状态 sni 阻断，甚至都不需要代理服务器
2 天前 回复了 CirnoSalt 创建的主题 › 宽带症候群 › 坐标 0471 联通宽带疑似开始限制连接数 |
问题是，如何确定是“不针对 pcdn 而是把所有用户一刀切”呢
15 天前 回复了 lanthora 创建的主题 › 宽带症候群 › WireGuard 跨国组网失败后,一个新工具的诞生 |
15 天前 回复了 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 ，而且组网功能完善。
16 天前 回复了 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 发出
系统的路由表实现源*目的匹配各种不方便，更别说超时了。这也是自己搓二进制的主要原因。
16 天前 回复了 maybeonly 创建的主题 › 宽带症候群 › 跟风贴自家软路由实现 |
@Jirajine
> 不过用户态一个函数能实现的功能在系统网络栈配合路由和规则做，正常来说最大的优势就是性能了。模块之间如果需要交流，那说明是耦合到一起的。
后面的 “交流” 指的是数据流转，比如后面挂了 3 个不同的梯子，那么数据总是得从调度进程到梯子进程的……不管整合不整合梯子都是 clash 既视感。
另一方面，在现实中，运维水平也是不得不考虑的……
所以这里的取舍是，选择 netns 集群便于维护的特点而放弃极致性能（其实也没多差）。
> 如果你的 vpn 入站需要路由除访问内部资源以外的流量，那是不是因为你这一套做了太多该在客户端做的，从而不够 portable 。
不是很确定你要表述什么。客户端连上入站 vpn 什么都能访问，就和连上 wifi 几乎一样（除了 2 层）。vpn 入站模块只需要路由器给转发特定端口就行。
现在的客户端可不是以前了，电脑怎么都好说，手机、平板、电视，IoT……还是设计哲学问题，我不想在客户端放复杂的东西，能连个不同的 ssid 就是极限了。
> 不过用户态一个函数能实现的功能在系统网络栈配合路由和规则做，正常来说最大的优势就是性能了。模块之间如果需要交流，那说明是耦合到一起的。
后面的 “交流” 指的是数据流转，比如后面挂了 3 个不同的梯子，那么数据总是得从调度进程到梯子进程的……不管整合不整合梯子都是 clash 既视感。
另一方面，在现实中，运维水平也是不得不考虑的……
所以这里的取舍是，选择 netns 集群便于维护的特点而放弃极致性能（其实也没多差）。
> 如果你的 vpn 入站需要路由除访问内部资源以外的流量，那是不是因为你这一套做了太多该在客户端做的，从而不够 portable 。
不是很确定你要表述什么。客户端连上入站 vpn 什么都能访问，就和连上 wifi 几乎一样（除了 2 层）。vpn 入站模块只需要路由器给转发特定端口就行。
现在的客户端可不是以前了，电脑怎么都好说，手机、平板、电视，IoT……还是设计哲学问题，我不想在客户端放复杂的东西，能连个不同的 ssid 就是极限了。
16 天前 回复了 maybeonly 创建的主题 › 宽带症候群 › 跟风贴自家软路由实现 |
@Jirajine
> 你用一堆 netns 组了个虚拟集群，数据包发过来发过去，这开销一点不比用户态低啊。
没错，参见设计目标第二条：并不是追求极致性能。
p.s. 即使是这样的耦合，即使效率可能比不上用户态，调试和修改起来也会比单个用户态程序容易太多了。以及用户态同样要面对和其他模块（比如 vpn ）交流的问题。
> 比如任何情况下任意客户端的任意 dns 请求和后续实际请求能够路由到相同的外部接口。
对于 dnsroute 列表内的域名来说，强保证同一个出口。
对于其他的，经过权衡利弊，故障切换比较重要，不保证同一个出口。否则对于 TTL 比较长的普通域名，靠前的隧道 up/down 会很难受。
> 路由器只要做好两件事：把不同客户端的出战连接路由到不同外部接口;追踪入站连接，回程路由到来源的接口。
这正是三个核心 GW+重要模块 DNSROUTE 的功能。如果需要依赖 DNS 做路由分流，那么这里混进一点 DNS 不可避免。
而且这里设计 DNSROUTE 只是“重要”，也就是说，必要的时候可以从核心模块上拆下来（当然功能也就没了）。
> 其他的你想用什么隧道、起什么服务、vpn 入站、通过 ip/mac/vlan 等方式识别客户端等等都是全部解耦、互不影响的。
这个确实全部解耦了。识别客户端在 INGW 中的 ingw.d 模块（还特别出现了 NET-XC ，就是为了把 VPN 入站的也拉过来），服务是单独的可拆卸模块（除了几个 DNS 是耦合度较高的），VPN 入站也是单独的模块（现在实现了 openvpn 和 wg 两个完全独立的模块），VPN 出站每个 VPN 抽象为一个隧道和其他 VPN 互不影响（串接除外）。
> 其他更复杂需求客户端自己做更合适。
算了，各种策略还是从路由器上下发吧，这是设计哲学的问题。ingw.d 很大程度上也是为了干这个。
> 你用一堆 netns 组了个虚拟集群，数据包发过来发过去，这开销一点不比用户态低啊。
没错，参见设计目标第二条：并不是追求极致性能。
p.s. 即使是这样的耦合，即使效率可能比不上用户态，调试和修改起来也会比单个用户态程序容易太多了。以及用户态同样要面对和其他模块（比如 vpn ）交流的问题。
> 比如任何情况下任意客户端的任意 dns 请求和后续实际请求能够路由到相同的外部接口。
对于 dnsroute 列表内的域名来说，强保证同一个出口。
对于其他的，经过权衡利弊，故障切换比较重要，不保证同一个出口。否则对于 TTL 比较长的普通域名，靠前的隧道 up/down 会很难受。
> 路由器只要做好两件事：把不同客户端的出战连接路由到不同外部接口;追踪入站连接，回程路由到来源的接口。
这正是三个核心 GW+重要模块 DNSROUTE 的功能。如果需要依赖 DNS 做路由分流，那么这里混进一点 DNS 不可避免。
而且这里设计 DNSROUTE 只是“重要”，也就是说，必要的时候可以从核心模块上拆下来（当然功能也就没了）。
> 其他的你想用什么隧道、起什么服务、vpn 入站、通过 ip/mac/vlan 等方式识别客户端等等都是全部解耦、互不影响的。
这个确实全部解耦了。识别客户端在 INGW 中的 ingw.d 模块（还特别出现了 NET-XC ，就是为了把 VPN 入站的也拉过来），服务是单独的可拆卸模块（除了几个 DNS 是耦合度较高的），VPN 入站也是单独的模块（现在实现了 openvpn 和 wg 两个完全独立的模块），VPN 出站每个 VPN 抽象为一个隧道和其他 VPN 互不影响（串接除外）。
> 其他更复杂需求客户端自己做更合适。
算了，各种策略还是从路由器上下发吧，这是设计哲学的问题。ingw.d 很大程度上也是为了干这个。
16 天前 回复了 maybeonly 创建的主题 › 宽带症候群 › 跟风贴自家软路由实现 |
@povsister 这个问题思考过，并没有那么疼。
首先，基本上没可能解析到同一个 anycast ip 。大厂的 cdn ip 也是专用的。好吧，假设他真的解析到同一个 anycast ip 了。
其次，比较现实的情况是，使用了两个不同的 dns 解锁机，分别解析到商家的美国解锁机和日本解锁机上，那这俩 ip 显然也不一样。
第三，更现实的情况，真实场景下，同一个用户/客户端几乎不可能同时用 nf 和 dmm 。所以实现的时候有考虑源 ip*目的 ip 做匹配，假如电视上看 nf ，手机上玩 dmm ，那是一点都不会出问题的。就算在同一台机器上切换，只要别来回切，后续解析成功的规则会覆盖前一个，而之前建立的 tcp/udp 连接则不会断——这里 dns 解析的结果是缓存在递归里的，而 dnsroute 会把 ttl 改小让用户不要太久不请求。
整体上来讲，不可能完全避免这类问题，但是现在的实现，已经可以让这类问题发生的几率足够小了。
至于嗅探，还是算了吧，当时也考虑到 ech （当时还是 esni ），从开头就没有打算做。
首先，基本上没可能解析到同一个 anycast ip 。大厂的 cdn ip 也是专用的。好吧，假设他真的解析到同一个 anycast ip 了。
其次，比较现实的情况是，使用了两个不同的 dns 解锁机，分别解析到商家的美国解锁机和日本解锁机上，那这俩 ip 显然也不一样。
第三，更现实的情况，真实场景下，同一个用户/客户端几乎不可能同时用 nf 和 dmm 。所以实现的时候有考虑源 ip*目的 ip 做匹配，假如电视上看 nf ，手机上玩 dmm ，那是一点都不会出问题的。就算在同一台机器上切换，只要别来回切，后续解析成功的规则会覆盖前一个，而之前建立的 tcp/udp 连接则不会断——这里 dns 解析的结果是缓存在递归里的，而 dnsroute 会把 ttl 改小让用户不要太久不请求。
整体上来讲，不可能完全避免这类问题，但是现在的实现，已经可以让这类问题发生的几率足够小了。
至于嗅探，还是算了吧，当时也考虑到 ech （当时还是 esni ），从开头就没有打算做。
Select Language