@Jirajine 不工作的应用非常多，你试试就知道了。


@WhatTheBridgeSay 有可能，但好像没有现成的实现，之前曾打算自己开发一个，但好像大家的兴趣不大。NDP proxy 类似于 IPv4 下的 ARP proxy ，一种让两个广播域共享同一网段的 hack 。

@yzc27 路由器型号千奇百怪，无法统一回答。

@sky96111 PPPoE 下 WireGuard 的 MTU 设定为 1412 就可以了。

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

@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 。

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

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

@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;
};
};

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

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

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

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

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

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

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

再举一个例子，假如本机 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 的回答也是错的。发包时发给谁完全遵循路由表，不存在提前判断是否同一网段这个步骤。

@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 发出。

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

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

纠正上述一处错误：

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

> 计算机发送 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 地址）。

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