我真的很迷恋Fortigate和Debian 9之间的IpSec VPN问题。
我的提供商为我提供了从侧面配置de Ipsec VPN的参数，并且我正在运行带有StrongSwan的Debian 9以创建隧道。
VPN似乎已启动（甚至我的提供商也已确认），但我无法通过隧道发送流量。
提供者（已取消）
VPN Network: 172.xx.x.0/16
Phase1:
Auth method: PSK
IKEv1
AES256
SHA-1
VPN Mode: Main Mode
Lifetime: 86400 seconds / 1440 min
Phase2:
Encapsulation: ESP
AES256
SHA-1
Lifetime 3600 seg
我的身边（带Strongswan的Debian 9）：
VPN Network: 10.xxx.xxx.128/26
Same parameters for the rest.
This server has only a private class C ip address (192.168.0.107), so there is not public ip address on any interface.
这是ipsec的状态
ipsec statusall
Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-3-amd64, x86_64):
uptime: 17 hours, since May 30 20:20:22 2019
malloc: sbrk 2433024, mmap 0, used 440080, free 1992944
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 9
loaded plugins: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke vici updown
Listening IP addresses:
192.168.0.107
Connections:
ipsec_vpn: %any...{PROVIDER_PUBLIC_IP} IKEv1, dpddelay=30s
ipsec_vpn: local: [{MY_PUBLIC_IP}] uses pre-shared key authentication
ipsec_vpn: remote: [{PROVIDER_PUBLIC_IP}] uses pre-shared key authentication
ipsec_vpn: child: 10.xxx.xxx.128/26 === 172.xxx.xxx.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
ipsec_vpn[2]: ESTABLISHED 17 hours ago, 192.168.0.107[{MY_PUBLIC_IP}]...{PROVIDER_PUBLIC_IP}[{PROVIDER_PUBLIC_IP}]
ipsec_vpn[2]: IKEv1 SPIs: 015c09277c35862a_i f6b88c417b659596_r*, pre-shared key reauthentication in 6 hours
ipsec_vpn[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
ipsec_vpn{24}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cb6a5875_i e4b3e1bf_o
ipsec_vpn{24}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 20 minutes
ipsec_vpn{24}: 10.xxx.xxx.128/26 === 172.xxx.xxx.0/16
ip xfrm状态
ip xfrm state
src 192.168.0.107 dst {PROVIDER_PUBLIC_IP}
proto esp spi 0xe4b3e208 reqid 1 mode tunnel
replay-window 0 flag nopmtudisc af-unspec
auth-trunc hmac(sha1) 0xbd02dd9589091d4294632f44d1f25a606804809e 96
enc cbc(aes) 0x6bb518f6f211217d9224544f69e8765175379e75b562c4eeea649c6b8c5a3f4d
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src {PROVIDER_PUBLIC_IP} dst 192.168.0.107
proto esp spi 0xc4fc4277 reqid 1 mode tunnel
replay-window 32 flag nopmtudisc af-unspec
auth-trunc hmac(sha1) 0x8ae132f87ee31a6b84c8c850a822037a188735ad 96
enc cbc(aes) 0x1c9dd67a2bbea69edf7eed7bed0863540f11c1b4fa8ee6aa161cc65fb0f616a7
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 192.168.0.107 dst {PROVIDER_PUBLIC_IP}
proto esp spi 0xe4b3e1bf reqid 1 mode tunnel
replay-window 0 flag nopmtudisc af-unspec
auth-trunc hmac(sha1) 0x3520769cd54a8dc5e4ef08480369f6e8324d5780 96
enc cbc(aes) 0x2be00973b99b7a79823590034b5628257f8c2ce5a1ce2a103270fdc070ae5e52
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src {PROVIDER_PUBLIC_IP} dst 192.168.0.107
proto esp spi 0xcb6a5875 reqid 1 mode tunnel
replay-window 32 flag nopmtudisc af-unspec
auth-trunc hmac(sha1) 0x0ef68a8c92de41a160d03ecee0db5d810e833ab4 96
enc cbc(aes) 0x34dfd4c7986a51a47134fe1889936fdc25ab9913aeed338d9f5433d941471914
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
...和ip xfrm策略状态
ip xfrm policy
src 172.xx.x.0/16 dst 10.XXX.XXX.128/26
dir fwd priority 189248 ptype main
tmpl src {PROVIDER_PUBLIC_IP} dst 192.168.0.107
proto esp reqid 1 mode tunnel
src 172.xx.x.0/16 dst 10.XXX.XXX.128/26
dir in priority 189248 ptype main
tmpl src {PROVIDER_PUBLIC_IP} dst 192.168.0.107
proto esp reqid 1 mode tunnel
src 10.XXX.XXX.128/26 dst 172.xx.x.0/16
dir out priority 189248 ptype main
tmpl src 192.168.0.107 dst {PROVIDER_PUBLIC_IP}
proto esp reqid 1 mode tunnel
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
src 0.0.0.0/0 dst 0.0.0.0/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 dst ::/0
socket out priority 0 ptype main
在某些论坛上阅读的内容中，我需要一个IP路由表220，但没有一个：
ip route show table 220
这是我的/etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
我的配置：
/etc/ipsec.conf
config setup
charondebug="all"
uniqueids=yes
strictcrlpolicy=no
conn ipsec_vpn
authby=psk
left=%defaultroute
leftid={MY_PUBLIC_IP}
leftsubnet=10.xxx.xxx.128/26
right={PROVIDER_PUBLIC_IP}
rightsubnet=172.xx.xx.0/16
ike=aes256-sha1-modp1024
esp=aes256-sha1!
keyexchange=ikev1
keyingtries=0
ikelifetime=86400s
lifetime=3600s
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=start
installpolicy=yes
route -n命令的结果：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
169.254.169.254 192.168.0.254 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
如您所见，VPN查找为UP。但是，当我想从另一端访问主机时，Debian尝试通过默认网关（通过Internet）而不是通过VPN来访问它们。
有什么想法吗？。