就是需要把 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

要看 ip 地址的话，浏览器打开按 f12 就好了，或者可以抓包，路由器上也应该能看见。
但是，跟你说，一个 ip 可能既在亚洲又在美洲，你从亚洲连就在亚洲，从美洲连就在美洲，这完全可能发生。
如果 cdn 没有告诉你他在哪儿（比如写在 header 里）的话，通常没有什么好办法知道他在哪儿。

特殊需求还是有必要，一般用户没必要了。
如果我想搞俩宽带，那就必须用自己的核心路由器。
还有给下面再划子网，v4 可以二级 nat ，v6 就不优雅了。
软路由当核心路由器，自己下发什么都能做（就是折腾）。

至于猫的性能，倒不觉得现在会有问题。

你为啥要用代理啊？ nat 可能更方便。
nat 的话直接
iptables -t nat -A POSTROUTING -o eth2 -i eth0 -j SNAT --to 58.49.223.15
再加一条类似的
就得了。
因为你新建对外连接的 tcp 的时候，和你连入的 ip 无关，而是要通过路由表选择 srcip 的。
如果你的代理软件能设置 srcip 或者 fwmark ，就设置。
如果不能，考虑 netns 解决所有问题。
注意 rpfilter 。

运营商直接把用户自己改的桥接改回路由不是欠投诉吗……
应该有点门槛。如果不知道自己在做什么，或者单纯为了网速，就不要改。

多个 ip 多条路
特别是往境外
当然，多出来的路也不一定好走
而且还有一些地方 icmpv6type2 的问题还没解决好的
除非明确知道自己在干什么，否则不建议普通上网使用
可以考虑不开 radvd ，只给下载机 /nas/路由器静态分配 v6 地址+snpt

看起来像是中间人 RST 攻击，但不一定是运营商。
(a) 中间人是因为，你后续收到了来自真正服务器的正确 ACK （ 188 ）。
(b) 说不一定是运营商是因为，后续的 ACK 和异常的 RST 间隔很小，只有 1ms 。也有可能是网站方面配置不当。

可以查看数据包的 TTL ，通常中间注入的数据包和普通数据包 TTL 不同。
至于 tcping 的时间，从抓包的结果来看，rtt 就是 10ms 左右。
至于本地代理，不太相信本地代理需要 10ms 才能建立 tcp 握手，基本排除。

@geekvcn zerotier 不也是 udp 吗？只是 hysteria 有自己的拥塞控制而已。多线程也是一定程度上缓解了丢包的问题，tcp 换用 bbr 呢，是不是可以有提升？

就是哪儿丢包吧。有点玄乎了。
在这种情况下，传输速率和 tcp 还是 udp 无关，和拥塞控制有关。