@oovveeaarr #57 fake-ip 仅仅只解析给爬墙的域名，既然爬墙的域名必须走代理，那么爬墙的流量的网络的完整性还有必要吗？对于国内域名，获得的 IP 地址是真实 IP ，在国内流量里，是完整的网络。icmp 等协议都是一样的跑法。

> ping www.bilibili.com
PING www.bilibili.com(240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30)) 56 data bytes
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=1 ttl=56 time=8.10 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=2 ttl=56 time=9.11 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=3 ttl=56 time=8.89 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=4 ttl=56 time=9.95 ms
64 bytes from 240e:97d:2000:c0e::30 (240e:97d:2000:c0e::30): icmp_seq=5 ttl=56 time=9.65 ms
^C
--- www.bilibili.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 8.102/9.138/9.949/0.640 ms
> ping www.bilibili.com -4
PING (59.36.228.17) 56(84) bytes of data.
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=1 ttl=56 time=4.86 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=2 ttl=56 time=5.31 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=3 ttl=56 time=6.23 ms
64 bytes from 17.228.36.59.broad.jm.gd.dynamic.163data.com.cn (59.36.228.17): icmp_seq=4 ttl=56 time=4.36 ms
^C
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 4.359/5.189/6.231/0.689 ms
> ping www.google.com
PING www.google.com (198.18.0.3) 56(84) bytes of data.
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=1 ttl=60 time=1.33 ms
64 bytes from 198.18.0.3 (198.18.0.3): icmp_seq=2 ttl=60 time=1.06 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.056/1.193/1.330/0.137 ms


> traceroute -n www.bilibili.com
traceroute to www.bilibili.com (59.36.228.17), 30 hops max, 60 byte packets
1 10.89.0.1 1.180 ms 1.107 ms 1.103 ms
2 *.*.*.* 2.914 ms 3.292 ms 3.240 ms
3 14.148.6.89 2.624 ms 14.148.6.81 2.461 ms 14.148.6.89 2.555 ms
4 14.148.2.149 3.421 ms * *
5 * 183.61.221.138 9.633 ms 183.59.12.2 5.502 ms
6 * * *
7 59.39.4.62 3.892 ms 183.57.144.2 3.880 ms *
8 * * *
9 59.36.228.17 4.533 ms 4.185 ms 6.581 ms
>
> traceroute -n6 www.bilibili.com
traceroute to www.bilibili.com (240e:97d:2000:c0e::32), 30 hops max, 80 byte packets
1 240e:*:*:*::1 0.323 ms 0.302 ms 0.273 ms
2 240e:1e:8000::56 1.701 ms 1.837 ms 1.735 ms
3 240e:1e:851d:2::1 1.501 ms 240e:1e:851d:1::1 1.462 ms 240e:1e:851d:4::1 1.471 ms
4 240e:1e:8401:12::1 2.844 ms 2.833 ms 240e:1e:8400:10::1 4.915 ms
5 240e:1f:d000:ff00::3 5.146 ms 6.149 ms 240e:1f:d000:46::3 6.292 ms
6 240e:1f:d000:83::3 4.908 ms 5.018 ms 240e:1f:d000:85::3 7.331 ms
7 240e:97d:2000:900::69 4.145 ms 240e:1f:d809::e:3 6.757 ms 240e:1f:d809::c:3 8.398 ms
8 240e:97d:2000:900::65 3.519 ms 240e:97d:2000:900::69 6.590 ms 240e:97d:2000:c0d::3 5.176 ms
9 240e:97d:2000:c0d::1 7.611 ms 240e:97d:2000:c0d::3 5.074 ms 240e:97d:2000:c0e::32 4.462 ms
> traceroute -n www.google.com
traceroute to www.google.com (198.18.0.3), 30 hops max, 60 byte packets
1 10.89.0.1 0.418 ms 0.317 ms 0.306 ms
2 172.16.222.2 0.914 ms 0.935 ms 0.885 ms^C

“旁路由”，在传统网络上是不存在这种说法，只有单臂路由，策略路由。
其实什么路由都无所谓，能解决问题就是好路由。
每个人也有适合他自己的解决方案，自己觉得好就行了。
最佳实践，这个看哪个角度了，例如你觉得硬路由做主路由，其他需要爬的机器采用修改网关 dns 来实现出墙功能，那么你觉得这样方便维护，那么是没问题的。
我最早折腾是搞 openwrt 做主路由，当年还没有什么插件，都是自己手动搭的，根据 IP 表分流，dnsmasq+ipset+ iptables+ss-libev （ redir ）+pdnsd 组合来解决 dns 污染和分流代理
但是这种组合维护特别不方便，ss 的服务更新，分流出问题了调试麻烦（组件太多）
后来 surge 出现后，陆陆续续的 ios 小火箭 qx 等基于规则的代理工具也出现，clash 也同步出现，逐渐成为了主流工具。
我也把 openwrt 的代理工具换成了 openclash 。
优点是：有 web 面板，切换节点，日志查看都非常方便。
缺点：openclash 想做 clash 的 web ui 客户端，想把 clash 的配置全部丢到 web 上方便用户配置和修改，确实做的很棒，但这样脚本的代码量非常大。试过几次因为 openclash 更新订阅的时候可能因为网络抖动问题下载下来的是空文件，但他不会校验（现在不知道会不会）。导致 clash 直接不启动了，不启动他也没有清理 iptables 等配置导致直接断网。（现在应该修复了？没再用了）

后来了解到 Mikrotik RouterOS ，就入了一台弱电箱神器。开始玩 Mikrotik 系列路由
对于本来就是学网络的人，routeros 其实比较适合，界面直观，配置概念完全是按照网络概念设计，如果你熟悉网络通信原理，熟悉防火墙配置，那么玩 ros 其实并不难。

但换了这个硬路由，爬墙怎么搞呢。我一开始也学大家一样，做“旁路由”（其实就是多层 NAT 路由），那么根本没法解决 openwrt 单点故障的问题。而且 NAT 转换效率，根本没有发挥硬路由的优势。

后来搜到的解决方案都是说例如你某个机器要爬，可以让 dhcp 服务器根据不同的 mac 地址分配不同的网关，或者是手动设置网关和 dns 。

我觉得这种方案太麻烦了，例如我某个设备今天突然需要访问一下 google ，只是突然需求，我还得电脑开机路由上配置，即使 Mikrotik 有手机客户端，我也需要等待 dhcp 生效，或是手动配置网关和 dns 。

我认为这个需求能直接从主路由上解决他们，后来也了解到各种代理工具都在用 faek-ip 方案。理解了工作原理之后，我就针对家里现有的网络拓扑进行修改。

最终采用 硬路由+dns 分流+fake-ip （ shellclash ） 的方案：
优点：
- 完美的分流：分流完全取决 dns 规则，只要匹配规则才能拿到 fake-ip ，fake-ip 的流量才会跑到 openwrt 那边，国内流量是直接从主路由就出去了。根本不会到 openwrt 那边。
- 网络性能：所有流量都先到主路由，主路由根据路由表进行流量转发，这是硬件路由的强项，所以基本不会有性能消耗，即使是最垃圾的 tplink 家用路由器，他也能完美的完成这个需求。因为得益于 fake-ip 方案（出自 https://www.rfc-editor.org/rfc/rfc3089 ），出墙的流量不需要获得真实的 DNS ，也不需要等待 DNS 答复，能以最快的速度封装 IP 层后发起访问。
- 维护便利性：因为只采用 dns 分流，所以只需要关注 dns 分流情况即可，拿到 fakeip 的流量才会跑到 openwrt 那边去。如果 dns 炸了，脚本能够自动检查并切换主路由的 dns （ Mikrotik 带脚本功能）
- 完美兼容 ipv6：因为对于局域网设备而言，他们只有一个网关就是主路由，所以和普通的网络是一样的，ipv6 自然就不受影响，而爬墙流量，因为 dns 服务器回答 fake-ip ，根本没有 ipv6 地址，所以自然也不受影响。
- 自动愈合（ Mikrotik 独有）：通过 Mikrotik RouterOS 的脚本功能，定期检查 openwrt dns 服务，如果出现故障，立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。路由表则完全不需要管，因为运营商的 dns 不会回应 fake-ip 给你。
缺点：
- 依然存在（非主路由的）单点故障：因为 DNS 分流靠第三方服务，所以如果 DNS 服务器挂了，会导致整个网络的域名解析出现问题。我做法上面也说了，如果出现故障，立即切换 ROS 的 DNS 上游服务器为运营商 DNS 。
- 对非网络专业人员而言，有配置难度。（其实所有透明代理都需要解决 dns 和路由问题，只是人家把这个过程放到 openwrt 脚本里帮你自动配置而已）

这方案我已经用了快两年，几乎 0 运维。这也是我个人认为翻墙网络的最好实践

删除没用的，他要控制你，直接可以加回来的。

@YongXMan #9 那么最好的做法还是用主路由来控制转发流量，这样就有一个很清晰的路由表去表达流量的走向。iptables 的 redir 或者 tproxy 方式，调试起来也是很费劲。特别是 openwrt 这种系统，各个网络插件都要对 iptables 修改一下。难免出现兼容问题，前端按一下，不看他又臭又长脚本，根本不知道他做了啥。

@YongXMan #5 https://www.v2ex.com/t/947864#r_13206481 参考这里的方案，不一定要旁路由，可以部署在一个路由上的。

原理是前置 DNS 分流，匹配 fake-ip 才发送给 clash 。如果嫌麻烦就直接虚拟多一个 op 。

dns 分流，匹配域名才用 clash 解析。

443 80 默认被 ben 如果路由是光猫，需要配光猫的防火墙。另外先试试 fe80 的地址通不通，不通检查程序是否监听在 ipv6 上

@MSIAM https://www.v2ex.com/t/947864
参考这个帖子我的方案

管理区域其实就是 IP 段嘛，openclash 不支持只代理某个 IP 段嘛？

打开他又臭又长的 bash 脚本，然后找到 iptables 命令 改成你自己的。
https://github.com/vernesong/OpenClash/blob/9ee0f02ed7615a62f960c9ee2f951dd1b47e2411/luci-app-openclash/root/etc/init.d/openclash#L2337-L2338

一坨坨。

冷知识 1 英里（迈）约等于 1.609 千米(公里)

# 允许 DHCPv6 客户端尝试前缀代理
/ipv6 firewall filter add action=accept chain=input \
comment="Accept DHCPv6 client prefix delegation" \
dst-port=546 protocol=udp src-address=fe80::/10

先确认 ipv6 dhcp client 端口在防火墙那边 input 是允许先吧。

@LisaSue 惜字如金。

回楼主：“你可样，房牵融，需包烟可解”

拿去当地电脑城找人修吧。

话说 445 安全吗？感觉还是套个 vpn 或者 ss 最好吧。
@Leslie5205912 看剧套个 webdav 安全很多。至少只能下载不能上传啊。445 有命令通道。隔三差五会爆 0day

@strp 额 是没听过 https://acme.sh ？要 80 443 才能更新证书已经上古时代的事。

openwrt 是用 dnsmasq 代理的，所以本机 nslookup 就是 127.你得看 dnsmasq 的上游 dns ，命令行是 uci show dhcp

话说 445 安全吗？感觉还是套个 vpn 或者 ss 最好吧。

只能事件查看器，但是卡的一批