Martin Melka's questions

我正在尝试将 OpenVPN 访问服务器配置为通过在 OpenVPN 服务器上建立的 IPSec 隧道路由某些流量。这些是寻址细节：

• OpenVPN 客户端 IP 范围：10.0.1.0/24
• OpenVPN 服务器 IP（客户端连接到的地方）：x.x.x.x
• IPSec 隧道对等体：y.y.y.y
• IPSec 隧道子网：(x.x.x.x) 10.0.1.0/24 <--> 172.30.239.0/25 (y.y.y.y)

从 OpenVPN 客户端来看，预期的行为是这样的：

• curl 172.30.239.75-> 流量将从客户端流向 OpenVPN 服务器，通过 IPSec 隧道路由，最终进入172.30.239.0/25网络
• curl google.com-> 流量将通过其默认网关从客户端到 OpenVPN 服务器和公共互联网（根本不使用 IPSec 隧道）

我认为这种配置会“正常工作”，因为 OpenVPN 客户端的 IP 地址是从与 IPSec 隧道相同的子网分配的，但遗憾的是事实并非如此。

我可以直接从 OpenVPN 服务器访问远程 IPSec 子网，例如curl 172.30.239.75，因此隧道和一些路由正在工作。但是从 OpenVPN 客户端运行相同的请求只是超时（tcpdump表明请求到达 OpenVPN 服务器但它在那里结束）。

我完全不知道接下来应该尝试什么。你能帮帮我吗？我对此很陌生，因此非常感谢您提供详细的答案！这个问题与我之前提出的这个问题有关，但没有足够的细节来实际实现。

下面我尝试收集相关配置，但如果还有其他重要的内容，请告诉我。

我没有添加任何自定义接口、路由或 iptables 规则。我尝试过的所有这些要么没有任何效果，要么搞砸了，所以下面的输出是 OpenVPN 和 IPSec 配置的。

接口

$ ifconfig (truncated)
as0t0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.0.1.1  netmask 255.255.255.128  destination 10.0.1.1

as0t1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.0.1.129  netmask 255.255.255.128  destination 10.0.1.129

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet x.x.x.x  netmask 255.255.252.0  broadcast x.x.x.x

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.7.177  netmask 255.255.252.0  broadcast 10.1.7.255

路由

下面[gw.gw.gw.gw]是eth0 iface默认网关的IP地址

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 eth0
10.0.0.0        10.1.4.1        255.0.0.0       UG    0      0        0 eth1
10.0.1.0        0.0.0.0         255.255.255.128 U     0      0        0 as0t0
10.0.1.128      0.0.0.0         255.255.255.128 U     0      0        0 as0t1
10.1.4.0        0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.169.254 10.1.4.1        255.255.255.255 UGH   0      0        0 eth1
x.x.x.0         0.0.0.0         255.255.252.0   U     0      0        0 eth0



$ ip route list table all
172.30.239.0/25 via [gw.gw.gw.gw] dev eth0 table 220 proto static src 10.0.1.1
default via [gw.gw.gw.gw] dev eth0
10.0.1.0/25 dev as0t0 proto kernel scope link src 10.0.1.1
10.0.1.128/25 dev as0t1 proto kernel scope link src 10.0.1.129
x.x.x.0/22 dev eth0 proto kernel scope link src x.x.x.x
broadcast 10.0.1.0 dev as0t0 table local proto kernel scope link src 10.0.1.1
local 10.0.1.1 dev as0t0 table local proto kernel scope host src 10.0.1.1
broadcast 10.0.1.127 dev as0t0 table local proto kernel scope link src 10.0.1.1
broadcast 10.0.1.128 dev as0t1 table local proto kernel scope link src 10.0.1.129
local 10.0.1.129 dev as0t1 table local proto kernel scope host src 10.0.1.129
broadcast 10.0.1.255 dev as0t1 table local proto kernel scope link src 10.0.1.129
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast x.x.x.0 dev eth0 table local proto kernel scope link src x.x.x.x
local x.x.x.x dev eth0 table local proto kernel scope host src x.x.x.x
broadcast 185.26.51.255 dev eth0 table local proto kernel scope link src x.x.x.x

iptables

iptables-save
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*nat
:PREROUTING ACCEPT [655:63952]
:INPUT ACCEPT [82:5300]
:OUTPUT ACCEPT [72:5613]
:POSTROUTING ACCEPT [72:5613]
:AS0_NAT - [0:0]
:AS0_NAT_POST_REL_EST - [0:0]
:AS0_NAT_PRE - [0:0]
:AS0_NAT_PRE_REL_EST - [0:0]
:AS0_NAT_TEST - [0:0]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j AS0_NAT_PRE_REL_EST
-A POSTROUTING -m state --state RELATED,ESTABLISHED -j AS0_NAT_POST_REL_EST
-A POSTROUTING -m mark --mark 0x2000000/0x2000000 -j AS0_NAT_PRE
-A AS0_NAT -o eth0 -j SNAT --to-source x.x.x.x
-A AS0_NAT -o eth1 -j SNAT --to-source 10.1.7.177
-A AS0_NAT -j ACCEPT
-A AS0_NAT_POST_REL_EST -j ACCEPT
-A AS0_NAT_PRE -m mark --mark 0x8000000/0x8000000 -j AS0_NAT
-A AS0_NAT_PRE -d 169.254.0.0/16 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 192.168.0.0/16 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 172.16.0.0/12 -j AS0_NAT_TEST
-A AS0_NAT_PRE -d 10.0.0.0/8 -j AS0_NAT_TEST
-A AS0_NAT_PRE -j AS0_NAT
-A AS0_NAT_PRE_REL_EST -j ACCEPT
-A AS0_NAT_TEST -o as0t+ -j ACCEPT
-A AS0_NAT_TEST -m mark --mark 0x4000000/0x4000000 -j ACCEPT
-A AS0_NAT_TEST -d 10.0.1.0/24 -j ACCEPT
-A AS0_NAT_TEST -j AS0_NAT
COMMIT
# Completed on Thu May 27 23:20:08 2021
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*mangle
:PREROUTING ACCEPT [48:3312]
:INPUT ACCEPT [19672:4609821]
:FORWARD ACCEPT [32480:9628950]
:OUTPUT ACCEPT [18602:11259270]
:POSTROUTING ACCEPT [51071:20887532]
:AS0_MANGLE_PRE_REL_EST - [0:0]
:AS0_MANGLE_TUN - [0:0]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j AS0_MANGLE_PRE_REL_EST
-A PREROUTING -i as0t+ -j AS0_MANGLE_TUN
-A AS0_MANGLE_PRE_REL_EST -j ACCEPT
-A AS0_MANGLE_TUN -j MARK --set-xmark 0x2000000/0xffffffff
-A AS0_MANGLE_TUN -j ACCEPT
COMMIT
# Completed on Thu May 27 23:20:08 2021
# Generated by iptables-save v1.8.4 on Thu May 27 23:20:08 2021
*filter
:INPUT ACCEPT [12:660]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [18526:11256230]
:AS0_ACCEPT - [0:0]
:AS0_IN - [0:0]
:AS0_IN_NAT - [0:0]
:AS0_IN_POST - [0:0]
:AS0_IN_PRE - [0:0]
:AS0_IN_ROUTE - [0:0]
:AS0_OUT - [0:0]
:AS0_OUT_LOCAL - [0:0]
:AS0_OUT_POST - [0:0]
:AS0_OUT_S2C - [0:0]
:AS0_WEBACCEPT - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j AS0_ACCEPT
-A INPUT -i lo -j AS0_ACCEPT
-A INPUT -m mark --mark 0x2000000/0x2000000 -j AS0_IN_PRE
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j AS0_ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j AS0_ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j AS0_WEBACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 943 -j AS0_WEBACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j AS0_ACCEPT
-A FORWARD -m mark --mark 0x2000000/0x2000000 -j AS0_IN_PRE
-A FORWARD -o as0t+ -j AS0_OUT_S2C
-A OUTPUT -o as0t+ -j AS0_OUT_LOCAL
-A AS0_ACCEPT -j ACCEPT
-A AS0_IN -d 10.0.1.1/32 -j ACCEPT
-A AS0_IN -j AS0_IN_POST
-A AS0_IN_NAT -j MARK --set-xmark 0x8000000/0x8000000
-A AS0_IN_NAT -j ACCEPT
-A AS0_IN_POST -d 10.0.1.0/24 -j ACCEPT
-A AS0_IN_POST -o as0t+ -j AS0_OUT
-A AS0_IN_POST -j DROP
-A AS0_IN_PRE -d 169.254.0.0/16 -j AS0_IN
-A AS0_IN_PRE -d 192.168.0.0/16 -j AS0_IN
-A AS0_IN_PRE -d 172.16.0.0/12 -j AS0_IN
-A AS0_IN_PRE -d 10.0.0.0/8 -j AS0_IN
-A AS0_IN_PRE -j ACCEPT
-A AS0_IN_ROUTE -j MARK --set-xmark 0x4000000/0x4000000
-A AS0_IN_ROUTE -j ACCEPT
-A AS0_OUT -j AS0_OUT_POST
-A AS0_OUT_LOCAL -p icmp -m icmp --icmp-type 5 -j DROP
-A AS0_OUT_LOCAL -j ACCEPT
-A AS0_OUT_POST -j DROP
-A AS0_OUT_S2C -s 10.0.1.0/24 -j ACCEPT
-A AS0_OUT_S2C -j AS0_OUT
-A AS0_WEBACCEPT -j ACCEPT
COMMIT
# Completed on Thu May 27 23:20:08 2021

我还尝试不让 OpenVPN 客户端 IP 子网和 IPSec 隧道子网重叠，但在这种情况下我也找不到设置路由的方法。不过，这种设置绝对是一种选择，如果那样的话会更好。

我正在尝试为 Ubuntu 服务器配置某种时间同步。服务器位于云提供商无状态防火墙后面。通过反复试验，我发现为了ntp工作，我必须打开传入的 UDP 端口 123。

然后我读到systemd-timesyncd现在首选使用，所以我尝试切换到那个。但这没有用。服务日志充满了

systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com).
systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.94.4:123 (ntp.ubuntu.com).

只有在我也将防火墙中的临时 UDP 端口列入白名单之后，32768–65535这才开始起作用：

systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

是否真的需要打开该范围的端口才能运行systemd-timesync？

编辑以回应@Jesus-Loves-You 在下面的回复。更高的端口应该不是必需的，但在我的情况下，出于某种原因，它们显然是必需的。查看服务日志systemd-timesync（由我用 注释#）：

# Before I enabled the 32786+ ports
May 21 11:49:21 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.89.198:123 (ntp.ubuntu.com).

# After I enabled the ports
May 21 11:49:06 myhost systemd-timesyncd[2656121]: Initial synchronization to time server 91.189.91.157:123 (ntp.ubuntu.com).

# After I disabled them again. Note that there are no log entries inbetween for almost
# three days. This, imo, pretty much proves that the ports are required.
May 24 09:29:34 myhost systemd-timesyncd[2656121]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com).

有关港口的更多信息：

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:42212           0.0.0.0:*                           2656121/systemd-tim

看起来42212是服务期望通信发生的端口。但几分钟后，当下一次轮询发生时：

root@host:/# netstat -ulpvn | grep systemd
udp        0      0 127.0.0.53:53           0.0.0.0:*                           2218041/systemd-res
udp        0      0 0.0.0.0:37240           0.0.0.0:*                           2656121/systemd-tim

现在端口变了。几分钟后，它再次变为51120。因此，我得出结论，该服务每次尝试同步时都会尝试在随机端口上进行通信。

我工作的一家小公司很快就要摆脱办公室了，我不得不将当前本地托管的 VPN（只是一个 Zyxel Zywall 110 设备）迁移到基于云的 VM 中。我在网络（后端开发转向操作）方面没有那么丰富的经验，所以我想验证以下方法是否可行。

我有一个专用的虚拟机，我在其中设置了 OpenVPN 访问服务器，基础运行良好，人们可以连接，一切都很好。

但是有一个问题，当前的 VPN 通过“隧道”将某个 IP 范围转发到合作伙伴公司的内部网络。它看起来像这样：

if dest_addr in '172.30.239.0/25':
    route through gw 194.xxx.xxx.xxx
else:
    route through gw 0.0.0.0

例如，当连接到 VPN 时，我的流量将按如下方式路由：

dest 1.2.3.4       => me -> VPN server -> its internet gateway -*-> 1.2.3.4
dest 172.30.239.10 => me -> VPN server -> partner network gateway (194.xxx.xxx.xxx) -(internal network routing)-> 172.30.239.10

从我们的路由器到合作伙伴公司的 VPN GW 的连接是通过带有预共享密钥的 IKEv1 完成的（从路由器的 Web UI 判断，因为这就是我拥有的所有“文档”）。

一些描述以下设置的 ascii 艺术作品。我正在用Router虚拟机替换。

            +-----------------+           [     Partner infra, this has to stay the same     ]
            | Router          |           194.xxx.xxx.xxx            e.g. 172.30.239.75
            | --------------- |   IKEv1   +-------------+       +-------------------------+
User -----> | 172.30.239.0/25-| --------> | VPN gateway |-----> | Internal network server |
            |     default     |           +-------------+       +-------------------------+
            |        |        |
            +--------+--------+
                     |
                     |
                 internet

OpenVPN 访问服务器本身不支持这样的东西（或者我无法找到该配置），所以我认为我可以在 VM 级别上做到这一点。如果我使用 Strongswan 之类的东西将操作系统连接到 VPN 网关并配置适当的路由iptables，这可以工作吗？连接到 OpenVPN 服务器并进入该172.30.239.0/25范围的用户的流量会被路由到 Strongswan 的连接，还是这种方法根本上是错误的？我有哪些选择？

谢谢！