V2EX › raysonx 的所有回复 › 第 4 页 / 共 89 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 89

❮

❯

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开个新坑：写给 Geek 们的小范围 IPv6 组网最佳实践

@veSir 需要。LUCI 上打开 Firewall 设置，点击 WAN 这个 zone 的设置，勾选 MSS clamping 。

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开个新坑：写给 Geek 们的小范围 IPv6 组网最佳实践

@Jirajine 纯 IPv6 内网可是个大坑，大量应用软件甚至不能支持在 NAT64 环境下工作（只有 iOS 是个例外，多亏了苹果的审核机制）。

> 一是地址管理问题，因为 Android 的原因，ipv6 地址没法用纯有状态管理，slaac+隐私扩展让地址完全无法管理，没法根据设备的地址单独配置防火墙等。

你有专门为 Android 设备配置防火墙的需求吗？目前我自己的网络环境下，不提供服务的终端设备都是在同一个 VLAN 下，这个 VLAN 默认不允许从外网发起连接的。如果要提供服务，我看还是放弃 Android 为好。

> 二是动态前缀问题。动态前缀让内网无法使用稳定地址，要稳定地址必须 nat ，但 nat 在 ipv6 里是 anti pattern ，坑也不少。很少有应用能支持在无状态前缀 nat 的情况下正确的地址发现。
国内 ISP 给家宽分配的 PD 前缀确实是动态的。其实按照规范，如果设备的 DUID 不变，在租期内 ISP 应当分配静态的 PD 前缀，只是 ISP 不遵守而已。
内网设备之间的通信还是用 ULA 吧。如果需要开放公网服务，只能建议用 DDNS 。

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开个新坑：写给 Geek 们的小范围 IPv6 组网最佳实践

@titanium98118 如果在路由器上做均衡只能 NAT ，因为个人用户没有自己的 PI （ provider-independent ）地址，比如你没法向电信宣告联通的路由。如果把在客户端做均衡，可以直接把多个公网地址分配到客户端。这个确实是一个值得讨论的话题。

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开个新坑：写给 Geek 们的小范围 IPv6 组网最佳实践

@xuangoer666
@pk000
跨地域组网肯定没有惟一方案，目前我是用 WireGuard + 动态路由协议。这个话题可以专门开一帖讨论。

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开个新坑：写给 Geek 们的小范围 IPv6 组网最佳实践

@silverwolf 请问区分设备的目的是什么？仅仅是为了在动态 IPv6 前缀的前提下给 N1 分配一个静态的 IPv6 地址来提供 DNS 服务吗？

除了使用 ULA 之外，还可以使用 fe80 开头的 link-local 地址，对于绝大多数操作系统，这个地址通常是固定的。

另外你还可以用第三个设备来跑 SLAAC 宣告一个 ULA 前缀，这个设备不必是你的路由器，这样所有设备都能拿到 ULA 地址，只需要记得不要宣告默认路由即可，比如用 radvd 的话，可以用下面的设置（ AdvDefaultLifetime 0 可以关闭默认路由宣告）：

interface eth0
{
AdvSendAdvert on;
prefix fd12:3456:7890:abcd::/64
{
AdvDefaultLifetime 0;
};
};

283 天前

回复了 raysonx 创建的主题 › 宽带症候群 › 开启 IPv6 后网速变得很慢？可能是 PMTU 黑洞的问题

@JimmyChan1506 我本来打算几篇文章系统讲一下配置家庭 IPv6 网络的最佳实践的，可惜这一拖就是两年。我下午写点简单的东西吧。

284 天前

回复了 fan88 创建的主题 › 宽带症候群 › 坐标湖南，新办移动企业专线，价格非常便宜

> 都说移动的宽带不行，实际安装体验下，目前没有什么特别差的情况
企业宽带和普通家用宽带的 QoS 级别不一样，优先级高。

286 天前

回复了 fanxasy 创建的主题 › 宽带症候群 › 家庭网络是否应该计算/存储分离？

我也建议重要数据专门用一台机器（甚至多台机器）存储，避免 all in boom ，

287 天前

回复了 FutureApple 创建的主题 › Windows › 看到了一篇 bitlocker 被警方解密的文章

没有绝对的安全。在分析信息安全的问题时，一定要先列出来威胁模型是什么，再进行防范。
如果已经有商业公司能“破解”（不管是真的破解还是由于配置不当产生的问题） bitlocker 硬盘加密了，说明类以的方法早就在黑客、黑产圈流传了，我们需要引起重视并寻找应对的方法。

普通人需要担心的是自己的电脑假如被偷、被借、修理、或者无人看管时被坏人盗取信息。至于楼上有人提到能不能防警方取证之类的，这根本不是技术讨论的范围。

290 天前

回复了 sonnyclarity492 创建的主题 › 云计算 › AWS LightSail 机器配置变了

lightsail 的流量在额度内是双向计费，而且内网流量也计费，超出额度后才入站流量和内外流量免费，而且和 ec2 一个价。
总的来说还是流量费便宜一些

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

我已经不想在这个问题上再做过多解释了，建议买本计算机网络的专业书看看。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

再举一个例子，假如本机 IP 是 192.168.1.100/24 ，外加一条 192.168.1.101/32 via 192.168.1.254 的静态路由，则本机向 192.168.1.101 发包时，就会发给 192.168.1.254 这个网关。

这个例子可以推翻楼上所有所谓先判断是否和本地同网段的论述，即使是 gpt 的回答也是错的。发包时发给谁完全遵循路由表，不存在提前判断是否同一网段这个步骤。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

@OrdinaryMan
> 我的理解是第一步是判断是否同网段，不同网段才会查路由表
你这理解完全是错的，而且完全没看我的回复。这楼上绝大多数人的回答都是错的，可见大多数程序员对网络只是一知半解，回答全凭臆测。

所谓掩码只是设定本机路由表的一种快捷方式。发包时，机器只是遵循路由表的设置，不会关心网段相同还是不相同的问题。不管同不同网段，如果手动加上路由条目，系统也会按照路由条目的指示来动作。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

驳“如果自己同时接入的多个网段有重合，而目标 IP 恰好在这个重合范围内，有可能计算机会使用错误的网络接口尝试与目标 IP 通信。”
假如本地同时有两张网卡，分别配置为：
eth1: 192.168.1.100/24
eth2: 192.168.1.101/23
这时候，系统会生成路由表：
local 192.168.1.100
local 192.168.1.101
192.168.1.0/24 dev eth1
192.168.0.0/23 dev eth2

如果往 192.168.0.1 发包，只会匹配到 192.168.0.0/23 dev eth2 ，所以会从 eth2 发出；
如果往 192.168.1.1 发包，会匹配前缀最长的 192.168.1.0/24 dev eth1 ，所以会从 eth1 发出。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

上述所有的回答中，只有 @blessingsi 和 @JayZXu 的回答是正确的，其他的要么错误，要么没回答到点子上。

发包时会匹配路由表，而不是看是否和本机是否同一子网。假设你本地的路由表有很多条目，会拿目的地址与每一条路由条目匹配（实际存在二分查找），找到最长前缀那一条，再决定下一步的动作。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

纠正上述一处错误：

在给 192.168.1.193 发送数据时，匹配到第 3 条路由，直接从“网卡 B”送出（目的 mac 地址为 192.168.1.193 的 mac 地址）。
在给 8.8.8.8 发送数据时，匹配到第 1 条路由，从“网卡 A ”经“网关 A”送出（目的 mac 地址为网关 A 的 mac 地址）。

292 天前

回复了 OrdinaryMan 创建的主题 › 程序员 › 一个关于计算机网络的疑问

> 计算机发送 ip 数据包时，如何判断目的 ip 和本地 ip 是否属于同一网段？
这个假设是错误的。发送 ip 数据包时，会通过查找路由表来决定发送的目的地，不会关心目的 ip 和本地 ip 是否属于同一网段。
实际上你本地计算机根本不知道目的 IP 的子网掩码，比如你往 8.8.8.8 发送数据，难道 Google 还需要暴露它的网络结构给你吗？

拿你的例子：
本地 ip：192.168.1.1 本地子网掩码：255.255.255.0
目的 ip：192.168.1.193 目的子网掩码：255.255.255.192

本机会生成路由表：
0.0.0.0/0 via 网关 A dev 网卡 A
local 192.168.1.1/32
192.168.1.0/24 dev 网卡 B

在给 192.168.1.193 发送数据时，匹配到第 3 条路由，直接从“网卡 A”送出（目的 mac 地址为 192.168.1.193 的 mac 地址）。
在给 8.8.8.8 发送数据时，匹配到第 1 条路由，从“网卡 B”经“网关 A”送出（目的 mac 地址为网关 A 的 mac 地址）。

293 天前

回复了 OLOrz1984 创建的主题 › 宽带症候群 › 求助关于 ros v7 获取不了 ipv6 前缀的问题

不知道 OP 所使用的 ROS 具体版本和硬件是什么，可以试试给 MikroTik 提一 bug 让其对 Server DUID
的检查不要那么严格： https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1 。
或者我来代为提交 bug 也可以，不过 MikroTik 对个人用户提的 bug 响应时间很慢就是了。

295 天前

回复了 oser 创建的主题 › 宽带症候群 › 发现广州联通宽带 ipv6 竟然没限制入站访问端口号

尽量别开 web ，有被运营商请喝茶的可能。

296 天前

回复了 OLOrz1984 创建的主题 › 宽带症候群 › 求助关于 ros v7 获取不了 ipv6 前缀的问题

先说结论，OP 所使用的当地运营商的 DHCPv6 服务器返回的消息格式存在 bug 。

按照 DHCPv6 的规范，服务器和客户端的 DUID 的组成格式为：2 个字节的 type code ，外加 1-128 字节可变长度的 identifier
（见 https://datatracker.ietf.org/doc/html/rfc8415#section-11 ）。

而 OP 给出的日志：
10:28:29 dhcp,debug,packet -> clientid: 00030001 0050568c 5e2f
10:28:29 dhcp,debug,packet -> serverid: 6660

客户端（ RouterOS ）的 DUID 是 00030001 0050568c 5e2f ，服务端的 DUID 是 6660 。
按照规范解读，客户端的 type code 是 0003 (DUID-LL)，hardware type 是 0001 ，后面的 0050568c 5e2f 是 link-layer 地址。
而服务端给的 DUID 是 6660 ，这只能解读为 type code 是 6660 （ RFC 中没有定义，应该是乱填的），然后没了。按照 RFC 的规定后面还要跟 1-128 字节的 identifier 。

所以结论就是，你的运营商的 DHCPv6 服务器响应的消息里 Server DUID 是乱填的（不知道谁开发服务器连 RFC 都不遵守），连长度都不对。RouterOS 报错且忽视了服务器的回应。

根本的解决方法是让运营商修服务器（可能性太低）或者换运营商。但我建议提出向 RouterOS 提一个 bug 吧，让 RouterOS 忽略这个错误就行了。

1 2 3 4 5 6 7 8 9 10 ... 89

❮

❯