服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Strongswan VPN隧道连接，但stream量不通过它
Intereting Posts
在Linux中的NTFS驱动器之间复制目录在目标驱动器上使用更多的空间 当文件夹名称包含空格时，如何从存储在文件中的名称创build文件夹？ 解决两个断开连接的专用networking的DNS查询 使用DISM failes将包添加到WinPE MySQL在白天总是占用200％到300％的CPU。 正常还是不好？ 如何在同一个实例上configurationMongoDB configsvr和仲裁器？ SSH蛮力攻击; 自动禁止IP地址 网关到网关超时 Amazon EC2实例上没有Web API控制器 只有nginx的日志率限制违规 升级HP P4000networking 如何启用networking映射？ 25TiB /从16TiB家，如何处理ext3？ HDD健康工具CentOS？ Ping一个IP地址以不同的IP响应

Strongswan VPN隧道连接，但stream量不通过它

我刚刚用strongswan（4.5）build立了VPN站点到站点的隧道。 隧道看起来很好，并连接到另一边，但似乎有一个问题路由通过隧道的stream量。

任何想法？

谢谢！

networking图 

+----------------------------------+ |Dedicated server: starfleet | +-----------------+ | | | CISCO ASA | | +-------------------------| internet | | | |eth0: XX.XX.XX.195/29 +-------------------| YY.YYY.YYY.155 | | +-------------------------| +------+----------+ | |virbr1: 192.168.100.1/24 | | | +----+--------------------| | | | | | | | | +-----------------+ | | | |network | | +-------+ | | | | | | |172.30.20.0/27 | | | | +-----------------+ | +------------------------------+ | | | kvm server: enterprise | | | | | | | | | | | | eth0: 192.168.100.100/24 | | | +------------------------------+ | +----------------------------------+

软件

  • debian wheezy
  • strongswan 4.5.2-1.5 + deb7u1
  • kvm和libvirt（192.168.100.xnetworking）

/etc/ipsec.conf 

 root@starfleet ~ # cat /etc/ipsec.conf # ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup plutodebug="all" plutostderrlog=/var/log/pluto-ipsec charonstart=no plutostart=yes conn net-net ikelifetime=86400s keylife=3600s rekeymargin=3m keyingtries=1 keyexchange=ikev1 authby=secret ike=aes256-sha-modp1024! esp=aes256-sha right=YY.YYY.YYY.155 rightsubnet=172.30.20.0/27 left=XX.XX.XX.195 leftsubnet=192.168.100.0/24 leftfirewall=yes pfs=no auto=add

Ipsec了 

 root@starfleet ~ # ipsec up net-net 002 "net-net" #1: initiating Main Mode 102 "net-net" #1: STATE_MAIN_I1: initiate 003 "net-net" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000] 104 "net-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2 003 "net-net" #1: ignoring Vendor ID payload [Cisco-Unity] 003 "net-net" #1: received Vendor ID payload [XAUTH] 003 "net-net" #1: ignoring Vendor ID payload [###############################] 003 "net-net" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series] 106 "net-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3 002 "net-net" #1: Peer ID is ID_IPV4_ADDR: 'YY.YYY.YYY.155' 002 "net-net" #1: ISAKMP SA established 004 "net-net" #1: STATE_MAIN_I4: ISAKMP SA established 002 "net-net" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1} 110 "net-net" #2: STATE_QUICK_I1: initiate 002 "net-net" #2: sent QI2, IPsec SA established {ESP=>0x8a12ab22 <0xa01abba1} 004 "net-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x8a12ab22 <0xa01abba1} root@starfleet ~ # ipsec status 000 "net-net": 192.168.100.0/24===XX.XX.XX.195[XX.XX.XX.195]...YY.YYY.YYY.155[YY.YYY.YYY.155]===172.30.20. 0/27; erouted; eroute owner: #2 000 "net-net": newest ISAKMP SA: #1; newest IPsec SA: #2; 000 000 #2: "net-net" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 3331s; newest IPSEC; eroute owner 000 #2: "net-net" [email protected] (0 bytes) [email protected] (0 bytes); tunnel 000 #1: "net-net" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 86050s; newest ISAKMP 000

networking信息

tun0接口被openvpn服务器使用。

virbr1接口是一个kvmnetworking 

 root@starfleet ~ # ip -4 as 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet XX.XX.XX.195/29 brd XX.XX.XX.199 scope global eth0 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0 5: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1 root@starfleet ~ # ip -4 rst 0 default via XX.XX.XX.193 dev eth0 10.8.0.0/16 via 10.8.0.2 dev tun0 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 XX.XX.XX.192/29 via XX.XX.XX.193 dev eth0 XX.XX.XX.192/29 dev eth0 proto kernel scope link src XX.XX.XX.195 192.168.100.0/24 dev virbr1 proto kernel scope link src 192.168.100.1 local 10.8.0.1 dev tun0 table local proto kernel scope host src 10.8.0.1 broadcast XX.XX.XX.192 dev eth0 table local proto kernel scope link src XX.XX.XX.195 local XX.XX.XX.195 dev eth0 table local proto kernel scope host src XX.XX.XX.195 broadcast XX.XX.XX.199 dev eth0 table local proto kernel scope link src XX.XX.XX.195 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 192.168.100.0 dev virbr1 table local proto kernel scope link src 192.168.100.1 local 192.168.100.1 dev virbr1 table local proto kernel scope host src 192.168.100.1 broadcast 192.168.100.255 dev virbr1 table local proto kernel scope link srr 192.168.100.1 root@starfleet ~ # ip xfrm state src XX.XX.XX.195 dst YY.YYY.YYY.155 proto esp spi 0x8a12ab22 reqid 16384 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x######################################## 96 enc cbc(aes) 0x################################################################ src YY.YYY.YYY.155 dst XX.XX.XX.195 proto esp spi 0xa01abba1 reqid 16384 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x######################################## 96 enc cbc(aes) 0x################################################################ root@starfleet ~ # ip xfrm policy src 192.168.100.0/24 dst 172.30.20.0/27 dir out priority 1847 ptype main tmpl src XX.XX.XX.195 dst YY.YYY.YYY.155 proto esp reqid 16384 mode tunnel src 172.30.20.0/27 dst 192.168.100.0/24 dir fwd priority 1847 ptype main tmpl src YY.YYY.YYY.155 dst XX.XX.XX.195 proto esp reqid 16384 mode tunnel src 172.30.20.0/27 dst 192.168.100.0/24 dir in priority 1847 ptype main tmpl src YY.YYY.YYY.155 dst XX.XX.XX.195 proto esp reqid 16384 mode tunnel src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main root@starfleet ~ # ip route show table 220 root@starfleet ~ # root@starfleet ~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 XX.XX.XX.193 0.0.0.0 UG 0 0 0 eth0 10.8.0.0 10.8.0.2 255.255.0.0 UG 0 0 0 tun0 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 XX.XX.XX.192 XX.XX.XX.193 255.255.255.248 UG 0 0 0 eth0 XX.XX.XX.192 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr1

iptables的 

 root@starfleet ~ # iptables-save # Generated by iptables-save v1.4.14 on Fri May 24 16:07:39 2013 *nat :PREROUTING ACCEPT [11:368] :INPUT ACCEPT [1:48] :OUTPUT ACCEPT [13:1012] :POSTROUTING ACCEPT [13:1012] -A POSTROUTING -s 10.8.0.0/16 ! -d 10.8.0.0/16 -o virbr1 -j MASQUERADE -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE COMMIT # Completed on Fri May 24 16:07:39 2013 # Generated by iptables-save v1.4.14 on Fri May 24 16:07:39 2013 *mangle :PREROUTING ACCEPT [271:19504] :INPUT ACCEPT [261:19184] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [181:28686] :POSTROUTING ACCEPT [181:28686] -A POSTROUTING -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Fri May 24 16:07:39 2013 # Generated by iptables-save v1.4.14 on Fri May 24 16:07:39 2013 *filter :INPUT ACCEPT [46:3380] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [36:5220] -A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT -A FORWARD -s 172.30.20.0/27 -d 192.168.100.0/24 -i eth0 -m policy --dir in --pol ipsec --reqid 16384 --proto esp -j ACCEPT -A FORWARD -s 192.168.100.0/24 -d 172.30.20.0/27 -o eth0 -m policy --dir out --pol ipsec --reqid 16384 --proto esp -j ACCEPT -A FORWARD -s 10.8.0.0/16 -o virbr1 -j ACCEPT -A FORWARD -i virbr1 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 192.168.100.0/24 -o virbr1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.100.0/24 -i virbr1 -j ACCEPT -A FORWARD -i virbr1 -o virbr1 -j ACCEPT -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable COMMIT # Completed on Fri May 24 16:07:39 2013

TcpDumping从192.168.100.100到172.30.20.9

所有命令同时运行。 

 root@enterprise:~# ping 172.30.20.9 PING 172.30.20.9 (172.30.20.9) 56(84) bytes of data. ^C --- 172.30.20.9 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 4999ms root@enterprise:~# tcpdump -v -n dst net 172.30.20.0/27 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:23:48.919819 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 1, length 64 16:23:49.918949 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 2, length 64 16:23:50.918950 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 3, length 64 16:23:51.918952 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 4, length 64 16:23:52.918954 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 5, length 64 16:23:53.918951 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.100.100 > 172.30.20.9: ICMP echo request, id 2605, seq 6, length 64 root@starfleet ~ # tcpdump -v -n dst net 172.30.20.0/27 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:23:50.475100 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 1, length 64 16:23:51.474262 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 2, length 64 16:23:52.474280 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 3, length 64 16:23:53.474251 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 4, length 64 16:23:54.474213 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 5, length 64 16:23:55.474173 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) XX.XX.XX.195 > 172.30.20.9: ICMP echo request, id 2605, seq 6, length 64

    starfleet上tcpdump会话的输出揭示了这个问题。 由于这里的NAT规则 

     -A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE

    源地址为192.168.100.100的ICMP请求获取到xx.xx.xx.195 。 由于协商的IPsec策略是来自192.168.100.0/24而不是xx.xx.xx.195stream量，因此这些数据包将不会被encryption。 在这个通过Netfilter的数据包stream程的示意图中可以看出，在任何查找IPsec变换（ xfrm查找 ）之前，都会应用nat表中POSTROUTING链中的规则。

    要解决这个问题，请执行以下操作之一 ：

    • 从MASQUERADE规则（ ! -d 172.30.20.0/27 ）中明确排除stream向目标子网的stream量

    • 在MASQUERADE规则之前添加一个明确的豁免规则 

       -A POSTROUTING -s 192.168.100.0/24 -m policy --dir out --pol ipsec -j ACCEPT

    • 将MASQUERADE规则保持原样，但leftsubnet=xx.xx.xx.195/32configurationleftsubnet=xx.xx.xx.195/32 （要求在Cisco ASA框中调整configuration，如果站点到站点的隧道实际上是您的目标，则不起作用）

    我的情况与@telemaco描述的情况非常相似。 我的笔记本电脑上有一些在KVM上运行的testing虚拟机。 我的笔记本电脑通过DHCP接收IP地址，因此VPN端点IP地址通过leftsourceip=%config由Strongswan分配给我的笔记本电脑。

    虚拟机使用专用networking192.168.100.0/24 。 我的笔记本电脑（KVM主机）通过DHCP接收IP地址192.168.50.2/24 ，从Strongswan接收IP地址10.0.0.10/26 。

    虚拟机应该访问通过VPN路由的networking192.168.0.0/24 。

    根据@ecdsa提供的答案，我通过添加下面的规则得到了这个工作： 

     -t nat -I POSTROUTING -s 192.168.100.0/24 -d 192.168.0.0/24 -j SNAT --to-source 10.0.0.10

    在我的情况下， ip xfrm policy看起来像这样（摘录）： 

     src 192.168.0.0/24 dst 10.0.0.10/32 dir fwd priority 2851 tmpl src xx.xx.xx.xx dst 192.168.50.2 proto esp reqid 5 mode tunnel src 192.168.0.0/24 dst 10.0.0.10/32 dir in priority 2851 tmpl src xx.xx.xx.xx dst 192.168.50.2 proto esp reqid 5 mode tunnel src 10.0.0.10/32 dst 192.168.0.0/24 dir out priority 2851 tmpl src 192.168.50.2 dst xx.xx.xx.xx proto esp reqid 5 mode tunnel

    这意味着只有本地IP地址10.0.0.10有一个相应的xfrm lookup规则。 这就是为什么需要NAT，除非将VM子网添加到IPsec。