我已经成功建立了 IPsec 连接，但它只部分起作用。一端没有通过隧道发送数据包。似乎这一端不清楚网络拓扑。
非常感谢您的帮助！谢谢！
这是网络方案：
"office"(192.168.73.0/24) == "vpn"(192.168.73.1) == "router"(6.6.6.6) <====> "server"(7.7.7.7) == "VM_LAN"(192.168.133.0/24)
6.6.6.6 和 7.7.7.7 是象征性的公网 IP，即“路由器”和“服务器”都直接连接到互联网。
“vpn”和“服务器”都运行 CentOS 6。“路由器”是电缆调制解调器，执行 NAT 和端口转发。
连接已建立。
在“vpn”上我可以 ping “服务器”的内部 IP：
[root@vpn]# ping 192.168.133.1
PING 192.168.133.1 (192.168.133.1) 56(84) bytes of data.
64 bytes from 192.168.133.1: icmp_seq=1 ttl=64 time=74.8 ms
在“服务器”上我无法 ping 通“vpn”，甚至没有发送出一个数据包。
下面是从“服务器”转储的显示上述 ping 数据包传入的信息。我使用相同的命令来测试当从“服务器”执行 ping 操作时，数据包是否从“服务器”发送到“vpn”，但没有出现任何数据包。
[root@server]# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:40:21.793577 IP 6.6.6.6.ipsec-nat-t > 7.7.7.7.ipsec-nat-t: UDP-encap: ESP(spi=0x712a1d37,seq=0x2), length 132
14:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,seq=0x2), length 132
ipsec 验证似乎没问题：
[root@server]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.6.32/K2.6.32-358.2.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel [OK]
SAref kernel support [N/A]
NETKEY: Testing for disabled ICMP send_redirects [OK]
NETKEY detected, testing for disabled ICMP accept_redirects [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for NAT-T on udp 4500 [OK]
Checking for 'ip' command [OK]
Checking /bin/sh is not /bin/dash [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
iptables 已禁用：
[root@server]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@server]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
7.7.7.7 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
0.0.0.0 7.7.7.1 0.0.0.0 UG 0 0 0 eth0
我的ipsec.conf：
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
# plutodebug="control parsing"
plutodebug="all"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private="%v4:192.168.73.0/24"
oe=off
# Enable this if you see "failed to find any available worker"
# nhelpers=0
conn aaa-office
authby=secret
left=7.7.7.7
leftsubnet=192.168.133.0/24
right=6.6.6.6
rightsubnet=192.168.73.0/24
rightid=192.168.73.8
auto=add
答案1
我会亲自回答，并希望这些信息对遇到同样问题的人有用。
根本原因是来自“服务器”的数据包没有通过隧道路由。使用后，ip xfrm policy我可以看到通过隧道路由的策略是数据包需要来自 192.168.133.0/24。
从“服务器”到“vpn”的 ping 操作产生了以下数据包：
17:29:16.549349 IP 7.7.7.7 > 192.168.73.8: ICMP echo request, id 43864, seq 1, length 64
因此，在执行 ping 时，使用的源 IP 自然是服务器的公共 IP。对于“vpn”机器来说情况并非如此，因为这台机器已经在子网中了。当我在“服务器”的配置文件中添加以下语句时，问题得到了解决：
leftsourceip=192.168.133.1
现在一切按预期进行，我可以从“服务器”访问“vpn”后面的子网。
答案2
我不知道 openswan，但是：在 VPN 隧道中，请确保您有一个基于路由的 VPN 或基于策略的 VPN。即如果它基于路由，则应该有一条路由说“使用此隧道接口到达 192.168.73.1 的网络”。如果它是基于策略的，那么应该有一条策略说“来自 x 的源流量发送到目标 y = 通过 VPN 隧道的隧道”
抱歉...删除了很多...阅读理解能力较差...我现在看到了您服务器的 LAN 接口/IP 上的信息，并且意识到您正尝试从 192.168.133.1 的源 IP 进行 ping 操作。
我仍然会验证 openswan 中是否在服务器端为 192.168.133.0/24 流量源（目的地为 192.168.73.0/24）设置了策略或路由，并确保它使用了隧道。看起来流量没有使用隧道，而是做了类似的事情：
192.168.133.1——尝试 ping 192.168.73.1（将会失败）