Проблема с подключением IPSec IKEv2 из Ubuntu 18.04 - PullRequest
Новая
       118

Проблема с подключением IPSec IKEv2 из Ubuntu 18.04

0 голосов
/ 03 октября 2019

Есть компьютер с Ubuntu 18.04, он расположен за маршрутизатором NAT и получает адрес в подсети 192.168.1.0/24. Например 192.168.1.11

Я подключаюсь с этого компьютера к VPN-серверу, используя протокол IPSec IKEv2 , но ни systemctl start strongswan, ни ipsec start не поднимают соединение, я могуподключиться только одним способом: 

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

После подключения я получаю адрес из подсети NAT на VPN-сервере 10.10.10.0/24 например 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 

:~# 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

Все конфигурации идентичны этому ресурсу .

1 Ответ

0 голосов
/ 14 октября 2019

На указанном ресурсе установлено leftsubnet=0.0.0.0/0. Это заставляет VPN-соединение по умолчанию маршрутизировать все через VPN. Так просто, если Ты можешь это изменить. Я также хочу сделать это (поэтому добавьте все открытые диапазоны в этот список и опустите частные диапазоны, возможно, кроме специального закрытого диапазона для доступа к локальной сети серверов). В противном случае Вам придется управлять своей локальной маршрутизацией на подключающемся клиенте «вручную». (Если обе стороны используют strongwan, должна быть возможность сузить его на другой стороне, не нарушая полностью SA, но не уверен, работает ли указание нескольких подсетей с IKEv1 между клиентом и сервером strongswan или нужно ли тогда определять несколько SA.)

Относительно "единственного способа установить соединение" ... Мне интересно, означает ли это, что у вас действительно есть пример конфигурации (ike2-rw в ipsec.conf) и запущен демон, и он не работает - но примерработает на сервере. У меня были проблемы со Strongswan на стороне сервера Ubuntu 18.04 (шлюз VPN), он подключался, но соединение не установилось. Клиент я не пробовал. Но я обнаружил, что пакет Ubuntu 18.04 сломан (или был несколько месяцев назад) и обновил Ubuntu. С 19.04 это работает как шарм. (Что говорит Ваш журнал для службы strongswan и системного журнала - или лучше /var/log/charon.log, когда вы пытаетесь вызвать клиента согласно документации?)

...