LibreSwan IKEv1 XAUTH VPN服务器 – 如此接近，但迄今为止

这里是我的情况的ASCII艺术图

192.168.10.0/24 | +---+ .7 | | A |------+ _____ +---+ | ( ) | .254 +---+ Ext IP ( ) +----Ri| R |Re-------( cloud ) | +---+ ( )\ iPhone | \ (_____) \ +---+ \ ------| | \ | B | \ 192.168.11.80 | | +------VPN-Tunnel---------| | IKEv1 XAUTH with PSK +---+ Legend: A - Windows 7 R - CentOS 6.9 acting as a router and iptables firewall, with LibreSwan installed Ri - Internal interface of R Re - External interface of R B - An iPhone SE with iOS 10 configured to use what Apple calls "IPSEC" (Cisco) VPN

系统R多年来一直是桥接模式下的工作路由器/ iptables防火墙。

我需要能够使用MS的iOS远程桌面客户端从iOS设备Blogin到系统A，并决定在R上设置VPN服务器。

你可能会问： “为什么不使用带有端口转发的SSH客户端” ？你会有一个很好的观点，这是我曾经做过的事情，但是在iOS 6的某个地方，Apple停止了允许后台应用程序保持networking连接的打开，从而使后台SSH隧道成为不可能。目前没有声称支持端口转发的SSH客户端可以在后台打开连接超过90秒，所以完成我的目标需要一个VPN。

我使用LibreSwan的指令设置了一些东西

问题摘要

VPN连接正常，但从B到A的路由似乎被中断，而包括从A到B的路由在内的所有其他事情似乎都能正常工作。

平matrix

  To A Ri Re B A - yyy From R y - - y BN yy -

换句话说，除了B不能ping 192.168.10.0/24networking中的任何人，同时仍然能ping通R的内部networking地址，每个人都可以ping其他人。

这里是ipsec.conf ：

 config setup protostack=netkey logfile=/var/log/pluto.log interfaces="%defaultroute" dumpdir=/var/run/pluto/ nat_traversal=yes virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10,%v4:!192.168.10.0/24 keep_alive=60 conn xauth-psk authby=secret pfs=no auto=add rekey=no left=%defaultroute leftsubnet=0.0.0.0/0 rightaddresspool=192.168.11.80-192.168.11.90 right=%any cisco-unity=yes modecfgdns1=192.168.10.254 leftxauthserver=yes rightxauthclient=yes leftmodecfgserver=yes rightmodecfgclient=yes modecfgpull=yes xauthby=file ike-frag=yes ikev2=never

ipsec verify输出：

 Verifying installed system and configuration files Version check and ipsec on-path [OK] Libreswan 3.15 (netkey) on 2.6.32-696.10.1.el6.x86_64 Checking for IPsec support in kernel [OK] NETKEY: Testing XFRM related proc values ICMP default/send_redirects [OK] ICMP default/accept_redirects [OK] XFRM larval drop [OK] Pluto ipsec.conf syntax [OK] Hardware random device [N/A] Two or more interfaces found, checking IP forwarding [OK] Checking rp_filter [OK] Checking that pluto is running [OK] Pluto listening for IKE on udp 500 [OK] Pluto listening for IKE/NAT-T on udp 4500 [OK] Pluto ipsec.secret syntax [OK] Checking 'ip' command [OK] Checking 'iptables' command [OK] Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options [OK] Opportunistic Encryption [DISABLED]

ipsec look输出ipsec look ：

 janus.localdomain Thu Sep 7 20:01:38 PDT 2017 XFRM state: src xxx.xxx.45.71 dst xxx.xxx.94.61 proto esp spi 0xde18dd2e reqid 16397 mode tunnel replay-window 32 flag 20 auth hmac(sha1) 0x23faf136fcde2c1b8c31f4cc9fea0003fa2985d2 enc cbc(aes) 0x04c42120ad0357f2406c5a9fdfe3f5ad8fcc45c3ed3aa69aeb1f010f996e3a10 encap type espinudp sport 42703 dport 4500 addr 0.0.0.0 src xxx.xxx.94.61 dst xxx.xxx.45.71 proto esp spi 0x0aa354d9 reqid 16397 mode tunnel replay-window 32 flag 20 auth hmac(sha1) 0x3ecfa164b8455dfca08b985c8e1b326adba2fa2a enc cbc(aes) 0xb81e5bfa39b63e493fcce3b2104ee5f2dd2f81fe8a45ec7665dd182493e525f9 encap type espinudp sport 4500 dport 42703 addr 0.0.0.0 XFRM policy: src 0.0.0.0/0 dst 192.168.11.80/32 dir out priority 3104 ptype main tmpl src xxx.xxx.94.61 dst xxx.xxx.45.71 proto esp reqid 16397 mode tunnel src 192.168.11.80/32 dst 0.0.0.0/0 dir fwd priority 3104 ptype main tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61 proto esp reqid 16397 mode tunnel src 192.168.11.80/32 dst 0.0.0.0/0 dir in priority 3104 ptype main tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61 proto esp reqid 16397 mode tunnel src ::/0 dst ::/0 proto ipv6-icmp type 135 dir fwd priority 1 ptype main src ::/0 dst ::/0 proto ipv6-icmp type 135 dir in priority 1 ptype main src ::/0 dst ::/0 proto ipv6-icmp type 136 dir out priority 1 ptype main src ::/0 dst ::/0 proto ipv6-icmp type 136 dir fwd priority 1 ptype main src ::/0 dst ::/0 proto ipv6-icmp type 136 dir in priority 1 ptype main src ::/0 dst ::/0 proto ipv6-icmp type 135 dir out priority 1 ptype main src ::/0 dst ::/0 dir 4 priority 0 ptype main src ::/0 dst ::/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 ptype main XFRM done IPSEC mangle TABLES NEW_IPSEC_CONN mangle TABLES ROUTING TABLES 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.254 xxx.xxx.45.0/21 dev eth1 proto kernel scope link src xxx.xxx.94.61 169.254.0.0/16 dev eth0 scope link metric 1002 169.254.0.0/16 dev eth1 scope link metric 1003 default via xxx.xxx.45.1 dev eth1 unreachable ::/96 dev lo metric 1024 error -113 mtu 65536 unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:a00::/24 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:7f00::/24 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:ac10::/28 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 mtu 65536 unreachable 2002:e000::/19 dev lo metric 1024 error -113 mtu 65536 unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113 mtu 65536 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 NSS_CERTIFICATES Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI

连接的pluto.log条目

 Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [RFC 3947] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [XAUTH] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Cisco-Unity] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [FRAGMENTATION 80000000] Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Dead Peer Detection] Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal) Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: responding to Main Mode from unknown peer xxx.xxx.45.71 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R1: sent MR1, expecting MI2 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 18317: peer be hind NAT Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R2: sent MR2, expecting MI3 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28 Sep 7 20:14:39: | ISAKMP Notification Payload Sep 7 20:14:39: | 00 00 00 1c 00 00 00 01 01 10 60 02 Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: Main mode peer ID is ID_IPV4_ADDR: '10.148.35.161' Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: switched from "xauth-psk"[7] xxx.xxx.45.71 to "xauth-psk" Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: deleting connection "xauth-psk" instance with peer xxx.xxx.45.71 {isakmp=#0/ip sec=#0} Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3 Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: new NAT mapping for #5, was xxx.xxx.45.71:18317, now xxx.xxx.45.71:42703 Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_2 56 integ=OAKLEY_SHA2_256 group=MODP2048} Sep 7 20:14:39: | event EVENT_v1_SEND_XAUTH #5 STATE_MAIN_R3 Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: Sending Username/Password request (XAUTH_R0) Sep 7 20:14:54: XAUTH: User jhg: Attempting to login Sep 7 20:14:54: XAUTH: passwd file authentication being called to authenticate user jhg Sep 7 20:14:54: XAUTH: password file (/etc/ipsec.d/passwd) open. Sep 7 20:14:54: XAUTH: checking user(jhg:xauth-psk) Sep 7 20:14:54: XAUTH: User jhg: Authentication Successful Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: xauth_inR1(STF_OK) Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_XAUTH_R1 to state STATE_MAIN_R3 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute INTERNAL_ADDRESS_EXPIRY received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute APPLICATION_VERSION received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_BANNER received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_DOMAIN received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_DNS received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_INC received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_EXCLUDE received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_DO_PFS received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SAVE_PW received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_FW_TYPE received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_BACKUP_SERVER received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_UNKNOWN_SEEN_ON_IPHONE received. Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: modecfg_inR0(STF_OK) Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MODE_CFG_R1: ModeCfg Set sent, expecting Ack Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: the peer proposed: 0.0.0.0/0:0/0 -> 192.168.11.80/32:0/0 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: responding to Quick Mode proposal {msgid:9b886838} Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: us: 0.0.0.0/0===xxx.xxx.94.61[MS+XS+S=C] Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: them: xxx.xxx.45.71[10.148.35.161,+MC+XC+S=C]===192.168.11.80/32 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode {ESP/NAT=>0x0e7958fe <0xbbd3b5cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg} Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2 Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x0e7958fe <0xbbd3b5 cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg}

重新总结：VPN在pluto.log或/var/log/secure连接并validation正常，没有错误或任何可疑内容，但客户端B无法将其数据包路由到A子网，即使A主机可以ping通B.

我尝试过的一件事是将`ipsec.conf'中的interfaces行更改为

  interfaces="%defaultroute ipsec0=eth0"

但这没有效果，并没有创build一个名为ipsec0的接口。

题

我需要在我的configuration中更改路由才能正确发生，以便B可以与内部子网上的主机进行通信？

附注/附加信息

我注意到往返于远程VPN客户端的数据包路由似乎没有涉及到通常的路由机制。 ip命令没有显示ipsecn适配器，所以我想我不明白ipsec和路由如何交互。

路由器/防火墙R具有伪装function，可以输出stream量：

iptables-restore NAT表部分（ eth1是外部适配器）

 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o eth1 -j MASQUERADE

iptables-restoreinputfilter：

 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -j ACCEPT -A INPUT -i eth1 -j INPUT_FILTER :INPUT_FILTER - [0:0] -A INPUT_FILTER -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT_FILTER -p udp --dport 500 -j ACCEPT -A INPUT_FILTER -p udp --dport 1701 -j ACCEPT -A INPUT_FILTER -p udp --dport 4500 -j ACCEPT -A INPUT_FILTER -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT -A INPUT_FILTER -p 50 -j ACCEPT -A INPUT_FILTER -p 51 -j ACCEPT -A INPUT_FILTER -j DROP

但是由于没有VPN适配器，我不确定我会在这里更改。

对这个问题的解决scheme表明了对正在发生的事情有一个正确的心理模型的重要性。

简单地说，ipsec隧道工作得很好，但我需要调整路由器（R）和Windows机器（A上面）中的一些防火墙规则。

我曾假设/ ipsec正在提供某种虚拟networking接口来表示隧道，但由于某种原因，我看不到它，不知道在哪里find它。我终于find了命令

 ipsec_tncfg (5) - lists IPSEC virtual interfaces attached to real interfaces

但运行这给了

 [jhg@janus ~]$ sudo ipsec tncfg /usr/libexec/ipsec/tncfg: NETKEY does not support virtual interfaces.

在对数据包stream进行了一些有系统的分析之后，我得到了一些启发：

ipsec完全隐藏自己，并且所有隧道stream量看起来像是从外部世界进入隧道，但使用RFC-1918私有源地址。

通常情况下，使用RFC-1918源地址永远不会看到传入的stream量，并且我的iptables FORWARD链被configuration为静默地删除所有不是 – --state RELATED,ESTABLISHED 。

所以，简单的答案是在FORWARD链中添加一个规则，允许来自地址池范围的数据包被转发。在iptables-restore格式中：

 # THIS IS A TEMPORARY HACK TO DEMONSTRATE THAT IT FIXES THE ISSUE # IN A PRODUCTION ENVIRONMENT THIS WOULD BE A SECURITY RISK -A FORWARD_FILTER -i eth1 -s 192.168.11.64/26 -o eth0 -d 192.168.10.0/24 -j ACCEPT

_{我知道这是一个相对较小（但不是零）的安全风险，因为它现在允许有人在我的ISP的子网上放置一个恶意主机，在192.168.11.64/26范围内configuration，并通过我的防火墙。} _{我也知道有iptables的选项来限制这个洞只有ipsec（ – --m policy --pol ipsec ... ），但我必须阅读手册页，并做一些研究。} _{如果我不能得到这个工作，这是一个单独的问题。} _{当我得到它的工作，我会回来，并更新这个答案。}

这并不奏效，现在这些数据包已经达到了主机A的水平，但没有得到回应。但是，这很容易解释，因为Windows防火墙不能识别地址池子网，因此在那里添加防火墙规则最终使所有事情都按预期工作。

接下来是移动地址池覆盖内部局域网子网的一部分，这样我就可以省去Windows防火墙规则。但那是另一天。