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

Есть компьютер с 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 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

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


networking vpn ipsec iptables ufw
person Igor Lavrynenko    schedule 03.10.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

person EOhm    schedule 13.10.2019
comment
Сервер работает нормально, разные клиенты подключаются успешно, только клиент на ubuntu не подключается. Или при подключении через charon-cmd теряет доступ к nat - person Igor Lavrynenko; 15.10.2019
comment
Да, тогда опубликуйте журналы (journalctl -e -u strongswan, / var / log / syslog и /var/log/charon.log) с (повторного) запуска службы strongswan. Они покажут некоторые детали. Какая версия / ОС является сервером? (Просто для интереса, это не имеет ничего общего с проблемой конкретного клиента.) Если это не Ubuntu 18.04, это, вероятно, указывает на то, что stronswan на ubuntu 18.04 все еще не работает. - person EOhm; 15.10.2019