跨境家宽环境下的站点网络互通实践-HQY 一个和谐有爱的空间

vpn tag-wireguard tag-32 tag-108 mdui-typo" id="post-398" itemprop="articleBody" style="-webkit-tap-highlight-color: transparent;line-height: 1.8;overflow-wrap: break-word;margin: 15px 20px 20px;color: rgba(0, 0, 0, 0.87);font-family: -apple-system, 'Noto Sans', 'Helvetica Neue', Helvetica, 'Nimbus Sans L', Arial, 'Liberation Sans', 'PingFang SC', 'Hiragino Sans GB', 'Noto Sans CJK SC', 'Source Han Sans SC', 'Source Han Sans CN', 'Microsoft YaHei', 'Wenquanyi Micro Hei', 'WenQuanYi Zen Hei', 'ST Heiti', SimHei, 'WenQuanYi Zen Hei Sharp', sans-serif;font-size: 15px;text-wrap: wrap">

当下的实际情况是：

两地均有且只有ipv4的公网地址
公网地址不可靠，CN的地址会定期由于pppoe的拨号而变化，HK的地址较长一段时间不改变，但如果路由器重启则会发生变化
简单的拓扑结构如头图，CN内网有一台小主机可以部署vm机器，HK内网只有一台NAS，操作相对受限

方案一：Wireguard组网

想到site to site的组网，最简单的方式是使用Wireguard，同时加上对应的Allowed IPs，以下是CN侧的wg0.conf文件示例，对侧的配置只需要反过来写即可：

wg0.conf[Interface] Address = 10.8.0.1/24 ListenPort = 51820 PrivateKey = --- MTU = 1412 PostUp = iptables -I FORWARD -i wg0 -j ACCEPT; iptables -I FORWARD -o wg0 -j ACCEPT; iptables -I INPUT -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -D INPUT -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE [Peer] PublicKey = --- PresharedKey = --- AllowedIPs = 10.8.0.2/32 AllowedIPs = 10.145.1.0/24 Endpoint = x.x.x.x:51920 PersistentKeepalive = 30

两侧的VPN隧道启动后，由于不是在路由器上启动的Wireguard，均需要在路由器上配置一个静态路由，将对侧的LAN子网指向Wireguard服务器的地址，NAT的动作已经在PostUp的脚本里执行了。

方案二：Tun to Socks5

如果只是两侧的子网形成VPN通道那么方案一已经基本完成了，支持TCP/UDP/ICMP等的互通，但实际情况是：

由于CN到HK的ISP或其他的问题，导致Wireguard被干扰和QoS非常严重 – Wireguard通过UDP组网，HK侧的主机是NAS，使用udp2raw并不方便
由于CN侧的公网IP每4-5天的变化，导致Wireguard VPN会在IP地址变动后失效需要人工重启 – 尝试通过在wg0.conf中配置域名用于动态解析变动后的IP，但似乎Wireguard断开后不会自动重启接口，该解决方案无效

在这种情况下，就只能考虑到其他的方式来解决，例如将流量运行在一个可以稳定不被QoS和跨境的通道上。考虑到这两个需求，我尝试使用TCP协议加由HK主动发起对CN的请求流向来构建通道尝试解决使用Wireguard时发现的问题。

在CN侧的主机上部署FRPS，由HK侧作为客户端连入，启用tls加密。

GitHub
fatedier/frp
A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.

★ 87k

我选择在HK的NAS上部署一个Squid作为代理借助FRP暴露给CN使用，由于外侧有FRP的包裹，流量上并不会显示为直接的HTTP报文，且相比于传统的shadowsocks/trojan/v2ray等协议，由于不需要对内容进行加密，性能损失小。

相对应配置内容示例，frps部分（在路由器上做端口映射将7000端口暴露即可）：

frps.ini[common] bind_addr=0.0.0.0 bind_port = 7000 # dashboard可以根据需要开启 dashboard_addr=0.0.0.0 dashboard_port=7500 dashboard_user=sample dashboard_pwd=sample token = sample

frpc的部分：

frpc.ini[common] server_addr = --- # 填写域名，frpc会自动尝试重连 server_port = 7000 tls_enable = true token = sample [squid] type = tcp local_ip = 127.0.0.1 local_port = 3128 remote_port = xxx

将squid映射到内网后即可通过该代理访问HK内网，但要达到客户端零配置的目标还需要将代理转成tun接口。例如使用如下工具：

GitHub
heiher/hev-socks5-tunnel
A high-performance tun2socks for Linux/Android/FreeBSD/macOS/iOS/WSL2 (IPv4/IPv6/TCP/UDP)

★ 926

参考项目的readme文件启动程序，我们并不需要劫持所有的流量，将访问HK内网的IP指向tun接口路由即可：

ip route add 10.145.1.0/24 dev tun0

此时，FRPS的主机已经能访问HK内网，但如果需要达到CN的局域网其他主机也能访问HK的内网的目的，则同样需要配置静态路由和在FRPS主机上做NAT的转换：

# 以下为路由转发和NAT转换，静态路由需要再路由器上配置，ens18/tun0根据实际情况更改 iptables -A FORWARD -i tun0 -o ens18 -j ACCEPT iptables -A FORWARD -i ens18 -o tun0 -j ACCEPT iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

此时两侧的站点到站点的通路就算搭建完成，尝试进行一些测试查看结果（CN侧上传带宽为50Mbps，下载为1000Mbps，HK侧上下行均为1000Mbps）：