linux – 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/ 我已经成功建立了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”和“server”都运行CentOS 6.
“router”是一个有线调制解调器,进行NAT和端口转发.

建立连接.

在“vpn”上我可以Ping“服务器”的内部IP：

[root@vpn]# Ping 192.168.133.1Ping 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数据包.我使用相同的命令来测试从“服务器”发送数据包时是否从“服务器”发送到“vpn”,但是没有数据包显示.

[root@server]# tcpdump port 500 or port 4500tcpdump: verbose output suppressed,use -v or -vv for full protocol decodeListening on eth0,link-type EN10MB (Ethernet),capture size 65535 bytes14: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 13214:40:21.793650 IP 7.7.7.7.ipsec-nat-t > 6.6.6.6.ipsec-nat-t: UDP-encap: ESP(spi=0x840e6b76,length 132

ipsec验证似乎没问题：

[root@server]# ipsec verifyChecking 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 -nChain input (policy ACCEPT)target     prot opt source               destinationChain FORWARD (policy ACCEPT)target     prot opt source               destinationChain OUTPUT (policy ACCEPT)target     prot opt source               destination[root@server]# route -nKernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface7.7.7.7         0.0.0.0         255.255.255.255 UH    0      0        0 eth0169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth00.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=0conn 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

解决方法 我会自己回答并希望这些信息可以用于有同样问题的其他人.

根本原因是来自“服务器”的数据包未通过隧道路由.使用ip xfrm策略我可以看到通过隧道路由的策略是数据包需要来自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”机器的情况,因为这台机器已经在子网中.当我将以下语句添加到“server”的配置文件时,问题得到解决：

leftsourceip=192.168.133.1

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

总结

以上是内存溢出为你收集整理的linux – Openswan隧道,但只能在一个方向上工作全部内容，希望文章能够帮你解决linux – Openswan隧道,但只能在一个方向上工作所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。