以下是我的情况的 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
多年来，System R 一直是桥接模式下工作的路由器/iptables 防火墙。
我需要能够使用 MS 的 iOS 远程桌面客户端从 iOS 设备 B 登录系统 A，并决定在 R 上设置 VPN 服务器。
你可能会问“为什么不直接使用带端口转发功能的 SSH 客户端呢？”？你说的很有道理，我以前也这么做过，但在 iOS 6 左右，Apple 停止允许后台应用程序保持网络连接打开，这使得后台 SSH 隧道无法实现。目前没有一个声称支持端口转发的 SSH 客户端可以在后台保持连接打开超过 90 秒，所以要实现我的目标需要 VPN。
我使用以下说明进行设置自由天鹅
问题摘要
VPN 连接正常，但从 B 到 A 的路由似乎中断了，而其他一切，包括从 A 到 B 的路由，似乎都正常。
平矩阵
To
A Ri Re B
A - y y y
From R y - - y
B N y y -
换句话说，每个人都可以 ping 通其他人，但 B 无法 ping 通 192.168.10.0/24 网络内的任何人，但仍然能够 ping 通 R 的内部网络地址。
这是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：
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，但客户端 B 无法将其数据包路由到 A 子网，即使 A 主机可以 ping B。
我尝试过的一件事是将interfaces“ipsec.conf”中的行更改为
interfaces="%defaultroute ipsec0=eth0"
但这没有任何效果，并且没有创建一个名为的接口ipsec0。
问题
我需要在配置中进行哪些更改才能使路由正确进行，以便 B 可以与内部子网上的主机通信？
附注/附加信息
ipsecn我注意到，往返于远程 VPN 客户端的数据包路由似乎不涉及通常的路由机制。该命令没有显示任何适配器ip，所以我猜我还不明白 ipsec 和路由是如何交互的。
路由器/防火墙 R 已针对传出流量启用了伪装：
iptables-restoreNAT 表部分（eth1外部适配器）
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE
iptables-restore输入过滤器：
*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 适配器，我不确定在这里要进行什么更改。
答案1
这个问题的解决方案表明，对正在发生的事情有一个正确的心理模型至关重要。
简而言之，ipsec 隧道运行良好，但我需要在路由器（上面的 R）和 Windows 机器（上面的 A）上调整一些防火墙规则。
我曾假设/猜测 ipsec 提供了某种虚拟网络接口来代表隧道，但出于某种原因，我看不到它，也不知道在哪里可以找到它。我终于找到了命令
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.
在对数据包流进行了一些系统分析之后，我顿悟了：
ipsec 完全隐藏自己，所有隧道流量看起来都像是从外部世界非隧道进入的，但带有 RFC-1918 私有源地址。
通常情况下，您永远不会看到带有 RFC-1918 源地址的传入流量，并且我的 iptables FORWARD 链配置为默默丢弃所有不是--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并绕过我的防火墙。我还知道 iptables 中有选项可以将此漏洞限制为仅 ipsec（--m policy --pol ipsec ...），但我必须阅读手册页并进行一些研究。如果我无法使其工作，那就是另一个问题了。当我让它工作时，我会回来更新这个答案。
但这并没有起到什么作用，数据包现在到达了主机 A，但没有得到响应。但这很容易解释，因为 Windows 防火墙无法识别地址池子网，因此在那里添加防火墙规则最终使一切按预期工作。
接下来是将地址池移至覆盖部分内部 LAN 子网，这样我就可以省去 Windows 防火墙规则。不过那是另一天的事了。