我在尝试连接两个网络时遇到困难。
站点A：是位于不同位置的多个 VPS 和办公室工作站，它们通过 OpenVPN 连接到私有网络 10.113.0.0/24。每个都有自己的互联网接入和默认网关。OpenVPN 服务器有公共 IP 95.95.95.95，也代表 IPSec 端点。
站点B：是在 Edge Gateway 后面的 VMWare 云上构建的私有网络，公共 IP 为 212.212.212.212。
问题是 SiteB 中的主机无法从 SiteA 中的主机访问。同时它们可直接从 SiteA 端点访问。我确信我错过了一些非常简单和明显的东西。
SiteA 端点配置
配置文件
eth0 Link encap:Ethernet HWaddr 00:00:00:46:76:84
inet addr:95.95.95.95 Bcast:95.95.95.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:249492177 errors:0 dropped:395296 overruns:0 frame:0
TX packets:13730009 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39576084672 (39.5 GB) TX bytes:8388420192 (8.3 GB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.113.0.1 P-t-P:10.113.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:13968 errors:0 dropped:0 overruns:0 frame:0
TX packets:11554 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1069136 (1.0 MB) TX bytes:4425784 (4.4 MB)
IPSec 连接：
conn portal-vcd
authby=secret
auto=start
## phase 1 ##
ike=aes128-md5-modp1024
ikelifetime=28800
keyexchange=ikev1
## phase 2 ##
esp=aes128-sha1-modp2048
type=tunnel
leftid=95.95.95.95
left=95.95.95.95
leftsubnet=10.113.0.0/24
rightid=212.212.212.212
right=212.212.212.212
rightsubnet=10.200.0.0/24
从端点跟踪路由正常
traceroute 10.200.0.1
traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets
1 10.200.0.254 (10.200.0.254) 3.042 ms 2.979 ms 2.943 ms
2 10.200.0.1 (10.200.0.1) 3.457 ms 3.472 ms 3.051 ms
IP xfrm 策略：
ip xfrm policy
src 10.113.0.0/24 dst 10.200.0.0/24
dir out priority 2883
tmpl src 95.95.95.95 dst 212.212.212.212
proto esp reqid 1 mode tunnel
路线表：
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 95.95.95.254 0.0.0.0 UG 0 0 0 eth0
10.113.0.0 * 255.255.255.0 U 0 0 0 tun0
95.95.95.0 * 255.255.255.0 U 0 0 0 eth0
IPTABLES NAT：
Chain POSTROUTING (policy ACCEPT 174 packets, 12723 bytes)
num pkts bytes target prot opt in out source destination
1 96 5928 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec
2 0 0 MASQUERADE all -- * eth0 10.113.0.0/24 0.0.0.0/0
SiteA VPS 配置
如果配置：
eth0 Link encap:Ethernet HWaddr 00:00:00:34:22:23
inet addr:178.X.X.X Bcast:178.X.X.255 Mask:255.255.254.0
inet6 addr: fe80::200:ff:fe34:2223/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5599082 errors:0 dropped:48196 overruns:0 frame:0
TX packets:300211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:918538724 (918.5 MB) TX bytes:706426556 (706.4 MB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.113.0.2 P-t-P:10.113.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:384 errors:0 dropped:0 overruns:0 frame:0
TX packets:1590 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:80459 (80.4 KB) TX bytes:124217 (124.2 KB)
我添加了静态路由
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 178.X.X.X 0.0.0.0 UG 0 0 0 eth0
10.113.0.0 * 255.255.255.0 U 0 0 0 tun0
10.200.0.0 10.113.0.1 255.255.255.0 UG 0 0 0 tun0
178.X.X.0 * 255.255.254.0 U 0 0 0 eth0
Traceroute 显示数据包已发送到 10.113.0.1，但在我看来并没有路由到那里的 IPSec。
traceroute 10.200.0.1
traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets
1 10.113.0.1 (10.113.0.1) 1.887 ms 2.453 ms 2.452 ms
2 * * *
什么配置错误？谢谢！
根据@MadHatter 的评论进行编辑：
ICMP 请求的 Tcpdump #ServerA tun0：
tcpdump -n -n -i tun0 host 10.200.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
08:52:32.011631 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 10, length 64
08:52:33.011614 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 11, length 64
流量从隧道返回后，ServerA 上的 ACMP 响应的 Tcpdump：
tcpdump -n -n -i eth0 host 10.200.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:52:45.014288 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 23, length 64
08:52:46.014010 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 24, length 64
所有 iptables 规则的列表。正如 @MadHatter 在评论中所说，默认情况下转发必须处于打开状态。但我提到它适用于 tun0 -> eth0 流量，但对于 eth0 -> tun0 则不是。
iptables -L -n -v
Chain INPUT (policy ACCEPT 3380K packets, 1704M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 1095 packets, 91824 bytes)
pkts bytes target prot opt in out source destination
2886 236K DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0
2886 236K DOCKER-ISOLATION all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1020 85632 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
637 47172 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 105K packets, 13M bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
2886 236K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
24177 70M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
我添加了 eth0 -> tun0 的转发规则
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
而且它神奇地起作用了！HostA：
ping 10.200.0.1
PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data.
64 bytes from 10.200.0.1: icmp_seq=1 ttl=62 time=3.17 ms
64 bytes from 10.200.0.1: icmp_seq=2 ttl=62 time=2.88 ms
为@MadHatter 的 Karma +1。
答案1
我们曾经tcpdump检查过进出两个防火墙节点的流量。顺便提一下，tcpdump在现代内核中使用 {Open,Libre,Strong}S/WAN 可能会有点问题，因为在加密流量进出的接口上，可以看到纯文本流量只有当它离开而不是到达时。
尽管如此，通过tcpdump跟踪流程，我们已经确定 ICMP 回显请求一直从网络 A 传输到网络 B，并且响应一直传输到服务器 A（网络 A OpenVPN 服务器/IPSec 隧道崩溃点），但它们并没有通过它传递到 OpenVPN 客户端。
由于流量是向外转发的，因此流量转发没有一般问题，因此我们怀疑是防火墙规则的问题。您已添加一条规则以允许将流量从外部网络转发到 OpenVPN 接口tun0，并且已实现完全连接。
您可能希望稍微完善该规则，例如，使其明确应用于通过 IPSec 连接到达的流量
iptables -A FORWARD -i eth0 -o tun0 -m policy --pol ipsec --dir in -j ACCEPT
或者可能使其具有状态感知能力，但这些都是改进，取决于你。