Openswan 隧道向上,但只能在一个方向上工作

gra*_*hel 4 linux ipsec openswan

我已经成功建立了一个 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)
Run Code Online (Sandbox Code Playgroud)

6.6.6.6 和 7.7.7.7 是象征性的公共 IP,即“路由器”和“服务器”都直接连接到互联网。

“vpn”和“server”都运行 CentOS 6。“router”是一个电缆调制解调器,执行 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
Run Code Online (Sandbox Code Playgroud)

在“服务器”上,我无法 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
Run Code Online (Sandbox Code Playgroud)

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]
Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

我的 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
Run Code Online (Sandbox Code Playgroud)

gra*_*hel 8

我会回答自己,并希望此信息可用于其他有相同问题的人。

根本原因是来自“服务器”的数据包没有通过隧道路由。使用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
Run Code Online (Sandbox Code Playgroud)

所以在做ping的时候,自然使用的源IP就是服务器的公网IP。“vpn”机器不是这种情况,因为这台机器已经在子网中了。当我将以下语句添加到“服务器”的配置文件时,问题解决了:

leftsourceip=192.168.133.1
Run Code Online (Sandbox Code Playgroud)

现在事情按预期工作,我可以从“服务器”到达“vpn”后面的子网。