网线退休我是不信的，光纤坏了没法自己修，网线透明胶请战（至少能撑几天）
光纤还有伤眼的潜在风险，网线……漏电？ 48vpoe 虽然理论上会电人……但是皮也没那么脆吧。
所以网线还能跑 poe ，这一点是光纤无论如何都解决不了的。
其他，光纤自己问题，就 sc lc 口，都能恶心半天的。
就不说组网了，绝大多数用户分不清接入和组网。

另外，fttr 对于不会弄但是不差钱的客户是有用的，对这个论坛的用户基本上都是负面价值。

想多了 ipv4 至少战到 2038 之后
v6 的一堆问题没解决
感觉最近推 v6 都没有之前那么大力气了

以及，还 wifi7 ，国内有频谱搞 wifi7 吗？

当年北京联通割接掉公网，早上发现，直接 10010 就“您好，公网 ip ，谢谢”，然后对面“您十分钟后重新拨号即可”，然后过了 10 分钟重新拨号就回来了，相当干净没有废话。
话说现在感觉一个月 ip 没变过了……

国内家宽还能双向解析的？机房双向解析都一堆事儿……
按理说，单纯解析肯定没事
就算有 web 服务，如果对不认识的域名返回 403 或者 404 也没事
至于常见的路由器、nas 登录页有没有事，看人家心情

北京联通确实是这样的
理论上之前有一版免费的 iptv （频道少）
直到前几年收到短信加多少钱开通 cctv 3568 我才在想：哎？不是一直有这些台吗？
现在的新套餐似乎是必选 iptv 了，有的套餐是赠送

mptcp 可以不要求出口 ip 和端口相同，但是几乎找不到支持这东西的……而且 mptcp 到底算不算单线程也有的讨论。
quic 也是要求出口 ip 和端口相同的。

所以你的理解是对的，只能在二层聚合。

安全性没什么区别啊。但是如果你要做互通的话，就会感觉到放在路由器上方便太多了……否则还需要在路由器上把到 wg 网段的路由指向那个 wg 服务器。

@HashV2 wifi 也不一定不行，看窗户外边能不能直接看见，能直接看见的话上定向天线无线网桥。不过速度嘛……我用过一百多米跨楼的，便宜货，能跑 100Mbps 的水平吧。
当然能物理上走线是最好的。

就是需要把 openvpn 出来的流量引到旁路由上。
当然可以整个流量都引过去（改 nas 的网关），但是不确定是否能接受。

如果 nas 能操作，做一个新路由表，比如 3333
ip r a 0.0.0.0/0 via 10.1.1.3 table 3333
ip r a throw 10.0.8.0/24 table 3333
ip ru a from 10.0.8.0/24 table 3333

这种活放到路由（哪怕是旁路由）上方便得多。

可以当然是可以的，相当于 site2site vpn 了。
ref: https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/

但是根据 ov 模式的不同，有不同的具体步骤。看起来是 tap 模式了。tap 模式做这种事情简单地多（相对 tun 而言）
1.
a.如果你的 ov 是 tun 模式
在 ov 服务器上编辑 ccd 配置（假设你用了 net30 ）
ifconfig-push 10.8.0.10 255.255.255.252
iroute 192.168.2.0 255.255.255.0
这个 ccd 文件的文件名是你的 openvpn 用户名，位置由 server.conf 里的 client-config-dir 决定。
b. 如果你的 ov 是 tap 模式，跳过这一步。

2. 在 ov 服务器到公网上添加 nat 规则：
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -j MASQUERADE
以及任何你喜欢的 dnat 规则。但是 dnat 的时候有个问题，就是你内网的回包没法回到 openvpn 服务端上去……
解决这个问题的思路有两个：
i. 完成 dnat 之后立刻做一次 snat
iptables -t nat -A PREROUTING -d ${公网 ip} -p tcp --dport 12345 -j DNAT --to 192.168.2.x:12345
iptables -t nat -A POSTROUTING -o tun0 ! -s 10.8.0.0/24 -j SNAT --to 10.8.0.1
缺点是看不到真实的公网 ip 。
ii. 在 192.168.2.1 和 192.168.2.2 上做连接追踪，比这些还复杂，暂不推荐。

3. 在云端网关上（看起来是你那个云服务器，但真的是吗？）上添加路由，将 192.168.2/24 网段丢给 openvpn 的服务端
如果做不到，可以考虑通过 nat+端口映射的方式访问，类似从公网访问。
又或者在网络允许的情况下，在你云端所有的服务器上添加路由。
ip r a 192.168.2.0/24 via 10.8.0.1

a. 如果是 tun 模式
要丢给接口（通常是 tun0 ）
ip r a 192.168.2.0/24 dev tun0
b. 如果是 tap 模式
ip r a 192.168.2.0/24 via 10.8.0.1

4. 在家里的网关上（看起来是 192.168.2.1 ）添加到云端的路由
ip r a 10.8.0.0/24 via 192.168.2.2

5. 在家里 ov 客户端上添加到云端的路由
讲真这里由服务端下发路由是比较合适的……
a.如果是 tun 模式
ip r a 10.8.0.0/24 dev tun0
b. 如果是 tap 模式
通常可以跳过这一步，如果配置正确，你的 tap0 或类似接口上已经有相关路由。

6. 各处防火墙放行
无非是类似下面的东西
iptables -I FORWARD -s 192.168.2.0/24 -d 10.8.0.0/24 -j ACCEPT
iptables -I FORWARD -d 192.168.2.0/24 -s 10.8.0.0/24 -j ACCEPT
之类的，各处执行……

v4 和 v6 是两张网，一点关系都没有。
剩下的就可以想明白了。

理论上来讲，nat 本身不提供安全性。
虽然 snat 确实一定程度上充当了防火墙。
不过说实话，感觉现代系统默认都有防火墙。自己开口子是另一回事。

这其实还是扫端口，某种方式拿到你的 ip 之后扫端口； v6 不会被扫描指的是不会被扫段（例如从 192.0.2.0 扫到 192.0.2.255 看有哪些主机活着）
比较在意的是 80 和 443 居然开着。

本机 dns 是 127.0.0.53:53 的话，应该是开了 resolved （叫什么？反正是用 resolvectl 控制的那个东西），应当检查它的配置。
如果单纯是抓包抓到的这些的话，你的 dns 确实即刻 4a 解析失败了，没有拖累网速。
内网稳定的 dns 一般无需单独部署，一般用 op 上的 dnsmasq 即可，dhcp 直接下发该 dns 而不需要再经过其他设备中转。

emmmmmm
怎么说
给不给回 AAAA 记录和你用 v4 还是 v6 解析是完全无关的才对
虽然有一些有 bug 或者配置的 dns 服务器没能正确处理 AAAA 记录，但是和他本身有没有 v6 也没有关系才对
回 servfail 虽然不好，但是也不是完全不能接受的
至于 dig 的-6 参数，是指其应当通过 v4 还是 v6 解析……man 里边是这么写的
```
If no server argument is provided, dig consults /etc/resolv.conf; if an address is found there, it queries the name server at that address. If either of
the -4 or -6 options are in use, then only addresses for the corresponding transport will be tried. If no usable addresses are found, dig will send the
query to the local host. The reply from the name server that responds is displayed.
```
而且 dns 这东西是可以被缓存的，连续来同样的查询的话后续可能就是缓存命中而已（没命中的话就要向转发的 dns 查询或者自己做递归）
还有 traceroute 之类的不想让他反向解析的话加上-n 就好了，内网 ip 反解变成 bogon 并没有错。
最后……192.168.100.1 哪儿来的？不管用不用三层交换，建议还是直接下发可靠的 dns ，这个结论上倒是没有错。个人理解不直接使用运营商的 dns 的原因，一来是客户到运营商可能有些 rtt （特别是在 cpe 接入的场合），另一方面会在出口上产生大量的 dns 的 nat 。至于自家的三层交换这俩都不存在，那直接用可靠的内网 dns 就好了。

A. 显然不是。
————
Q. 本质上说，ipv4 为什么要 nat 啊？
A. 最常见的理由是，公网 ip 不够，需要共享同一个公网 ip 。
Q. 那么，为什么不能直接用 192.168.x.x 的 ip 上外边的网站，而一定要 nat 呢？
A. 答案是，因为 192.168.x.x 不是公网 ip 。
Q. 那么，为什么他不是公网 ip ？
A. 因为 RFC 里写了，他不是公网 ip 。
Q. 那我用一段 RFC 里规定的公网 ip 行不行，比如我把我家内网设置为 11.22.33.0/24 ？
A. 答案是仍然需要 nat ，本质是这些 11.22.33.x 的 ip ，别人找不到你；而运营商给你的那个公网 IP ，别人能找到你。
Q. 那他们为什么不看到 11.22.33.x 就来找我呢？
A. 因为你没有宣告路由，而且你不是这段 ip 的合法拥有者，别人也不会接受你的宣告。
Q. 那么，如果我买了 /租了一段合法的 ip ，然后花钱让运营商帮我宣告，我是不是就可以不用 nat 了？
A. 只从技术上来讲，是的。很多 IDC 商家就是这么做的，他们的路由器到运营商的链路上，通常有另一组（或多组）点对点的 IP 地址，和局域网内的地址完全不同，不用于上网只用于互联。
Q. 那么如果运营商给我分了一段 ip ，还帮我宣告了，我是不是就不用 nat 了？
A. Bingo ！ 2409:8a28:c1f:80c0:a0d3:9bb8:e792:6007 所在这一段（可能是 /64 或者更大）就是运营商帮你宣告了，访问这一段的数据包都会转发给你（被防火墙干掉的除外）。这些数据包是通过 2409:8a28:cf1:4ea7:3655:94ff:fe87:db49 这个地址转发的（运营商到你这一段通常是 dhcp-pd ）。
Q. 那运营商为什么要这么干，是不是剥夺了我做 nat 的权利？
A. 并没有。他这么干除了成本原因，也是给了你自己选择 nat 或者不 nat 的权力。如果你一定要，你仍然可以把出去的请求 nat 到你拥有的任何合法 ip 地址上。你所有对外访问的 v6 流量都用 2409:8a28:c1f:80c0::做源 ip ，完全可以实现。

1.分 vlan 只在特定 vlan 开启
2.ip6tables 干掉 ra/dhcpv6 看上面那个
3.
其实只要把来自你不喜欢的设备的 ipv6 请求都 drop 掉就行了，甚至可以做成白名单
这样设备会认为 v6 不可用而自动用 v4 ，即使他有 v6 地址
e.g.
ip6tables -A FORWARD -i br0 -m mac --mac-source 00:11:22:33:44:55 -j ACCEPT
ip6tables -A FORWARD -i br0 -j REJECT

你能弄到裸纤的话，是最便宜的。自己做两端设备就行，必要的情况下做两条做互备。
这种点对点的，除了大运营商外，也有小运营商在做，价格相对更便宜一些。
其他……emmm ，和裸纤比成本可能要差数量级……

@100240v 真公网。用了两年了。
每月 20 ，价格合理，童叟无欺，也能挡住没事瞎要的。
当然了，交钱了的，要是给假的就太不要脸了。
----
公网有什么特征？
1. 所有端口都通。
当然除了那几个被 ban 的。
2. 连接外网（指当地 isp 以外）的服务器，本机（持有公网 ip 的设备，如路由器）的源端口，和服务端看到的源端口一致。
特别是在连接一些知名网站 /cdn 的 443 端口的时候，如果是假公网，他最后需要 nat ，更不敢给你 nat 到同一个源端口，会出事。
3. 非 tcp 、udp 协议也能进来。
你可以从外网 ping 自己公网 ip 试试，看看来回的数据包能不能抓到。也可以用其他的，如 4 、47 之类的测试。

和中间有没有经过私网地址的路由、能不能连接到私网地址无关。
最简单的例子是，拿着真公网 ip 的路由器也能访问自己家局域网里的东西；另外现在很多正经机房都用私网地址做点对点 ip 了。

iptables -t nat -I POSTROUTING -p udp --sport 123 -j MASQUERADE --to-ports 60000-60100
ntp 这东西 虽然默认是 123 到 123 但是其实你不一定需要源端口也是 123