我已经成功build立了一个IPsec连接，但它只能部分工作。 一方不通过隧道发送数据包。 似乎networking拓扑结构对这方面还不清楚。
任何帮助，高度赞赏！ 谢谢！！
这是networkingscheme：
"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和端口转发。
连接build立。
在“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数据包进来。我使用相同的命令来testing数据包是否从“服务器”发送到“vpn”，从“服务器”ping时，但没有数据包显示。
[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
ipsecvalidation似乎确定：
[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
我会回答自己，并希望这个信息将可用于其他同样的问题。
根本原因是来自“服务器”的数据包没有通过隧道路由。 使用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”机器的情况，因为这台机器已经在子网中。 当我将以下语句添加到“server”的configuration文件时，问题解决了：
leftsourceip=192.168.133.1
现在事情按预期工作，我可以从“服务器”到达“vpn”背后的子网。
我不知道openswan，但是：在VPN隧道中，确保您有一个基于路由的VPN或基于策略。 即。 如果是基于路由，则应该有一条路由，指出“将此隧道接口送至192.168.73.1的networking”。 如果是基于策略的话，那么应该有一个策略：“从x发送到目的地的源stream量y =通过VPN隧道的隧道”
对不起…删除了很多…阅读理解不佳…我现在看到你的服务器的LAN接口/ IP的信息，并意识到你正在尝试从192.168.133.1源IP。
我仍然会validation在openswan中的策略或路由是否在服务器端为192.168.133.0/24stream量目标设置为192.168.133.0/24，并确保它使用隧道。 它看起来像交通不是使用隧道，而是做了这样的事情：
192.168.133.1 – – 试图ping 192.168.73.1（这会失败）