【问题标题】:Problem with connecting IPSec IKEv2 from Ubuntu 18.04从 Ubuntu 18.04 连接 IPSec IKEv2 的问题
【发布时间】:2020-02-01 21:11:48
【问题描述】:

有一台运行 Ubuntu 18.04 的计算机位于 NAT 路由器后面并接收子网192.168.1.0/24 中的地址。例如192.168.1.11

我使用 IPSec IKEv2 协议从这台计算机连接到 VPN 服务器,但 systemctl start strongswanipsec start 都没有提升连接,我只能通过一种方式连接:

sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username

连接后,我从 VPN 服务器 10.10.10.0/24 上的 NAT 子网获取地址,例如 10.10.10.11 VPN 工作,所有流量都通过隧道。但是到本地网络的连接完全消失了,从子网192.168.1.0/24 到地址192.168.1.11 以及从我的计算机到任何子网地址192.168.1.0/24 的请求都没有通过

输出ip a:

3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 18:d6:c7:14:ff:04 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.11/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
        valid_lft 562sec preferred_lft 562sec
15: ipsec0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.10.10.11/32 scope global ipsec0
        valid_lft forever preferred_lft forever
    inet6 fe80::5b2:78:42:d7/64 scope link stable-privacy 
        valid_lft forever preferred_lft forever

:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=0.067 ms
^C
--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4075ms
rtt min/avg/max/mdev = 0.067/0.069/0.072/0.010 ms

:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5105ms

所有配置都与这个resource相同。

【问题讨论】:

    标签: networking vpn iptables ipsec ufw


    【解决方案1】:

    引用的资源设置了leftsubnet=0.0.0.0/0。这会导致 VPN 连接默认通过 VPN 路由所有内容。最简单的就是如果你能改变它。我也想这样做(所以在该列表中添加所有公共范围并省略私有范围,也许除了一个特殊的私有范围来访问服务器 LAN)。否则,您必须“手动”管理连接客户端的本地路由。 (如果双方都使用 strongwan 应该可以在不完全破坏 SA 的情况下将其缩小到八边,但不确定指定多个子网是否适用于 strongswan 客户端和服务器之间的 IKEv1,或者您是否需要定义多个 SA。)

    关于“建立连接的唯一方法”...我想知道这是否意味着您真的有示例配置(ipsec.conf 中的 ike2-rw)并启动了守护进程,但它不工作 - 但示例正在工作在服务器上。我在 Ubuntu 18.04 服务器端(VPN 网关)上遇到了 Strongswan 的问题,它正在连接但连接不上。我没有尝试的客户。但是我发现 Ubuntu 18.04 包坏了(或者是几个月前)并升级了我的 Ubuntu。使用 19.04,它就像一个魅力。 (当您尝试根据文档启动客户端时,您的 strongswan 服务日志和系统日志是什么?或者更好的是 /var/log/charon.log?)

    【讨论】:

    • 服务器正常,各种客户端连接成功,只有ubuntu上的客户端连接不上。或者如果通过 charon-cmd 连接失去对 nat 的访问权限
    • 是的,然后从 strongswan 服务的(重新)启动发布日志(journalctl -e -u strongswan、/var/log/syslog 和 /var/log/charon.log)。他们会展示一些细节。服务器是哪个版本/操作系统? (只是出于兴趣,它与特定客户端的问题无关。)如果不是 Ubuntu 18.04,可能表明 ubuntu 18.04 上的 stronswan 仍然损坏。
    最近更新 更多