V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  tavimori  ›  全部回复第 1 页 / 共 7 页
回复总数  131
1  2  3  4  5  6  7  
7 天前
回复了 lysShub 创建的主题 宽带症候群 厂商的路由是怎么动态优化的?
国际网间路由是非常动态的,通常可以由服务商通过 BGP 协议控制,中间经过的运营商也会因为负载均衡,分流,海缆可用情况等等原因动态调节,观察下来一年中会变很多次。
你注意到的很可能不是针对性的“优化”,可能只是碰巧运营商网络割接、调整等等原因导致的。
10 天前
回复了 Cert 创建的主题 宽带症候群 联通 教育宽带 海外加速业务 AS9929
希望可以加群了解一下。👀
247 天前
回复了 Getting 创建的主题 WireGuard 关于 Wireguard 设置 Address /24 /33 疑问
Wireguard 在系统路由表建立路由其实有两个阶段。

第一个阶段是在系统加载虚拟网卡并设置网卡地址时。这时会读取 [Interface] 下的 Address ,设立相应的 IP 地址,如果是/24 的话,系统会自动对/24 增加一个路由,使得相关流量从该虚拟网卡走。

第二个阶段是使用类似 wg-quick 等工具时,这些工具会在基本操作之外读取你 [Peer] 下各个 peer 的 AllowedIPs 字段,并且将对应的段加到路由表,使得相关流量从该虚拟网卡走。


所以如果你是用 wg-quick (通常也包括 iPhone 客户端这类功能完整的 wireguard 前端),只要相应的 peer 下面的 AllowedIPs 包含需要的段的话,[Interface] 下面的地址设置成 /32 应该也是没有关系的。

与此相对的,在一些路由器上配置的 wireguard 并不会自动加载 AllowedIPs 路由(例如 RouterOS 就是这样),这种时候就需要通过设置虚拟网卡的 IP 地址和正确的前缀,或者手动增加路由条目来确保相应地址会走虚拟网卡。
260 天前
回复了 mantouboji 创建的主题 宽带症候群 这么高的丢包率?
这种不是去向丢包,是 icmp 反馈没有很积极,或者 icmp 包回程被丢了一部分。你的第七跳丢包率低就意味着你发过去的包在之前的几跳都是正常没有丢,只是前面几跳的路由器懒得搭理你给你反馈。
这是使用 mtr 或 traceroute 检查路由时的常见现象。
270 天前
回复了 journalist 创建的主题 宽带症候群 代理环境下的 IPv6 源 IP
@journalist 要使设备 A 使用 B 的地址作为源地址向服务器建立连接,那么目标 C 返回的包的目的地址就是 B 的地址。

如果设备 A 使用 socks5 ,tproxy 等代理技术,那么设备 A 必须能够拦截到目标 C 返回的发给 B 的包,并重新以代理响应的方式返回给 B ,这就要求目标 C 发给 B 的包在网络中一定得经过设备 A 。此外在 A 上实现这个功能也比较怪异,例如 socket 要绑定非本机 IP ,并且可能要注入一个特定的 ebpf 程序来劫持目标 C 返回的特定包。

也有一些特殊的做法可以满足你的要求,例如一个叫做 dae 的代理软件使用 ebpf 来过滤直连的流量,只要确保不启用 SNAT ,就可以实现你需要的功能。这类代理软件在处理直连的流量时行为完全与路由器是一致的。https://github.com/daeuniverse/dae/blob/main/docs/zh/how-it-works.md
云服务器是一种特殊的商品,他的特点是当机房有余量时,不管是否销售出去成本都是固定的。幻兽帕鲁游戏服务器几乎没有什么带宽开销,机房的算力又普遍冗余,所以云厂商提供短期的特别套餐,本质上是区分市场,赚取额外收益。
@jsq2627 上行流量会在用户接入侧就因爲带宽限制而丢包,不会给骨干网造成压力。但是这种丢包可能会严重影响使用,用户没有明确感知可能还是要归功于日常上传需求就比较小。
@Fucter @ambition117 @MossFox

其实咱也只是想用于一些低带宽、低延时的场景的。专线一般都是这种应用场景。
@lcy630409 @huluhulu @huaseky

不是觉得他们技术不行,主要是考虑到不少游戏是基于 P2P 联机,所以并不能建立一个白名单把所有潜在游戏玩家的 IP 都包括进来吧?只要用类似的方式进行 P2P 连接,应该很难区分是否是游戏流量吧?
2023-10-20 04:13:26 +08:00
回复了 louisxxx 创建的主题 Linux Wireguard 端口转发问题
Wireguard 套传输层代理的确不是建议的做法。在这一问题上现在市面上没有广泛知晓的好的解决方案。

我不太了解 gost 对 UDP 转发的处理,但是任何在 UDP 转发层面做的数据缓冲、多个包合并、套到 TCP 上之类的做法,都会导致利用该 UDP 建立的 wireguard 虚拟网里的传输层协议速率控制算法无法正常工作,在很多情况下会大幅劣化网络质量。

总的来讲,个人理解上 Wireguard 下面不要套东西才能比较良好的工作,起码是不能套 TCP 的东西。
2023-10-20 03:57:12 +08:00
回复了 louisxxx 创建的主题 Linux Wireguard 端口转发问题
是不是客户端上的 Wireguard 在改路由表时只会自动排除 Wireguard 服务器 B ?

这个取决于你在客户端上对“Wireguard 服务器 B”这一 peer 的 AllowedIP 字段的设置和是否有其他路由规则。

如果是 IPv4 的话,一个简单的 debug 方式是将服务器这一 peer 的 AllowedIP 字段设置成只有他虚拟网的 IP 地址,并以/32 结尾,这样的话在一般的配置情况下,不会带起全局的路由(如果设置成 0.0.0.0/0 ,就会带起全局路由),只会带起到服务虚拟网单一 IP 地址的路由。

在这样建立连接后可以看下 ping 服务测的虚拟网 IP 通不通。
2023-10-20 03:46:29 +08:00
回复了 louisxxx 创建的主题 Linux Wireguard 端口转发问题
由于常见的加密代理都会对 UDP 包二次封装,并且不会对超过可封装长度的 UDP 包进行分片,所以相关的 UDP 应用要预先对包大小进行限制。

由于不清楚 GOST 协议的头开销,作为保险的解决方法,建议在客户端和服务端的 wireguard 配置上都增加如下配置:
```
MTU=1280
```
如果上述做法有效,可以进一步通过 GOST 协议的头开销对 MTU 进行精确的设定。
2023-10-17 22:29:52 +08:00
回复了 SingeeKing 创建的主题 Apple 新 iPad 支持 eSIM!
从字面上看,似乎中国版 iPad 想要安装海外 esim 的话,只需要安装这一行为发生在境外就行,安装完后也可以漫游回境内使用。
之前用 Chrome 遇到过类似的问题,换个浏览器或者逐个禁用浏览器扩展排查一下就好了。
怀疑是某些插件在打开页面时进行了一些 blocking 操作。
可以使用支持多路径的四层代理协议来避免 TCP 乱序的问题。例如首先通过隧道组成两条并列的三层网络,然后传输层再使用 MPTCP 透明代理 TCP 流量。当然,如果没有需要单连接突破 100M 的需要的话,用 ECMP 之类的对不同连接进行负载均衡的方案就可以。
2023-06-09 12:49:51 +08:00
回复了 3dxfood 创建的主题 宽带症候群 wireguard 支持 IPv6 slaac 吗?
@raysonx 是的,从协议上看,主要是现在 wg 的内部路由不支持组播特性。如果是只有一个客户端和一个服务端的话,貌似只要把组播地址加到 AllowedIP 里好像还是有可能实现的。不过不知道现成的 SLAAC 协议服务支不支持 tun device 。
2023-06-05 02:57:33 +08:00
回复了 tavimori 创建的主题 程序员 AI 骚扰电话的死循环逻辑和攻击策略
@gtheone1 最近这批骚扰电话每个都提交 12321 举报了,接起来主要就是为了好玩。
2023-06-03 00:38:53 +08:00
回复了 tavimori 创建的主题 程序员 AI 骚扰电话的死循环逻辑和攻击策略
@duke807 我这次打了快七分钟,是我懒得实验主动挂了的。估计这是一个新供应商,还不懂节省话费。
2023-06-03 00:37:02 +08:00
回复了 tavimori 创建的主题 程序员 AI 骚扰电话的死循环逻辑和攻击策略
@LaurelHarmon 直接开骂貌似 AI 会知趣地挂掉。
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   994 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 20:21 · PVG 04:21 · LAX 12:21 · JFK 15:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.