御坂的学习笔记

记录
技术

(御坂0x4e21) #1

主要是同信息技术相关的笔记。


(御坂0x4e21) #2

VPN、非对称路由与 Windows 防火墙

背景

御坂网络的某两个站点采用 wireguard VPN 连接。由于其中一个站点 SiteA 的边界路由器为一款只有 8 MiB ROM 的 OpenWRT 设备,连 LuCI 都装不上,就更不要说额外安装 wireguard 相关软件包了。于是,御坂选择在路由器上转发 wireguard 使用的 UDP 端口到一台运行 AOSC OS 的服务器。拓扑如下:

设备 端口 IP
RA eth0 100.64.19.89
eth1 192.168.1.1
RB eth0 100.64.89.64
eth1 192.168.2.1
wg1 192.168.0.2
SVR1 eth0 192.168.1.11
wg1 192.168.0.1
网关 192.168.1.1
PC1 eth0 192.168.1.21
网关 192.168.1.1
PC2 eth0 192.168.1.22
网关 192.168.1.1

SVR1、PC1 运行 AOSC OS Core 5 “eMMC”
PC2 运行 Microsoft Windows 10 version 1803
RA、RB 运行懒得查版本号的 OpenWRT

RA 将某个(保密而又懒得编一个的)UDP 端口转发到 192.168.0.2。SVR1 和 RB 间建立 WireGuard 连接。在 RA 上设置静态路由,将 192.168.0.0/24 和 192.168.2.0/24 指向 SVR1。

事实上 100.64.19.89 是一个公网地址,因此它其实根本就不可能属于 100.64.0.0/10;100.64.89.64 确实是一个运营商级 NAT 后的地址,所以 WireGuard 连接只能由 SiteB 向 SiteA 发起。

问题

SiteA 下的 GNU/Linux 设备 SVR1、PC1 均可正常访问 SiteB。
SiteA 下的 Microsoft Windows 设备 PC2 无法与 SiteB 建立 TCP 连接,不论方向。
PC2 和 SiteB 上的设备能互相 ping 通。

排查过程

关闭 PC2 上的 Windows 防火墙,发现所有问题消失。
分析各设备路由表并作 traceroute,发现 PC1 到 RB 的数据包需要由 PC1 的默认网关 RA 转发给 SVR1,方能进入 WireGuard VPN;而 RB 到 PC1 只需要由 SVR1 直接 从 eth0 发出,即可由同网段的 PC1 收到,不需要经过 RA。

问题原因

PC1、PC2 与 RB 间形成了 非对称路由。出于预防 DOS 攻击的考虑,PC2 上默认开启的 Windows 防火墙自动屏蔽了非对称路由的 TCP 数据包。

解决方案

采用 iproute2 的多路由表功能配置策略路由,强制让 SVR1 将来自 WireGuard VPN 去往 192.168.1.0/24 网段的所有数据包统一指向默认网关,即 RA 上的 192.168.1.1。

在 SVR1 上编辑 /etc/iproute2/rt_tables,底部加入:

233     wireguard

在 SVR1 的 WireGuard 设置脚本中添加:

# ...
ip route add 192.168.2.0/24 dev wg1
# 以上为原先内容

# 新增内容
# 新增路由表
ip route flush table wireguard
ip route add 192.168.2.0/24 dev wg1 table wireguard
ip route add 192.168.0.0/24 dev wg1 table wireguard
ip route add default via 192.168.1.1 table wireguard
# 新增路由策略,指定某些源地址所用的路由表
ip rule add from 192.168.2.0/24 table wireguard
ip rule add from 192.168.0.0/24 table wireguard

最终结果

PC2 可在 Windows 防火墙开启的情况下正常访问 SiteB。