Настройка OpenConnect VPN через Network Manager

Это та же проблема, что и здесь: Получение работы openconnect vpn через gui, но мои дополнения к этому были удалены, и меня попросили создать новый вопрос.

На самом деле здесь есть множество людей, задающих похожие вопросы, все с 0 ответами.

Версии программного обеспечения: Ubuntu 14.04, openconnect 5.02

Основная проблема: Я пытаюсь добавить VPN-соединение в network-manager, используя openconnect. Когда я ввожу своё VPN-имя пользователя и пароль, соединение устанавливается успешно, но я не могу разрешить DNS.

Если я запускаю openconnect в терминале через sudo, DNS работает.

sudo openconnect -u <username> https://<vpn concentrator name>

Дополнительные сведения:

1a. При подключении через openconnect и network-manager, хотя я явно добавил DNS и домен поиска на вкладке ipv4, только домен поиска оказывается в /etc/resolv.conf. Даже если я не указываю DNS и домены поиска, я вижу в журналах, что эта информация поступает от VPN-концентратора. Тем не менее, домен поиска обновляется правильно. [лог ниже]

1b. При подключении через sudo в терминале, resolv.conf заполняется правильно с DNS и доменами поиска, даже если я не добавил эту информацию в командной строке или не предоставил путь к vpnc-script. Должно быть, он получает это от VPN-концентратора. [лог также ниже]

2a. При подключении через openconnect и network-manager создаётся новый интерфейс ‘vpn0’.

2b. При подключении через sudo и командную строку создаётся новый интерфейс ‘tun0’.

Журнал при подключении через network-manager:

NetworkManager[784]: <info> Запуск VPN-сервиса 'openconnect'...
NetworkManager[784]: <info> VPN-сервис 'openconnect' запущен (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN-сервис 'openconnect' появился; активируем соединения
NetworkManager[784]: <info> Состояние VPN-плагина изменено: init (1)

Здесь он запрашивает мой пароль

NetworkManager[784]: <info> Состояние VPN-плагина изменено: запуск (3)
NetworkManager[784]:    SCPlugin-Ifupdown: устройства добавлены (путь: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: устройство добавлено (путь: /sys/devices/virtual/net/vpn0, iface: vpn0): конфигурация ifupdown не найдена.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: не удалось определить драйвер устройства; игнорируем...
NetworkManager[784]: <info> VPN-соединение '<connection name>' (Подключиться) получен ответ.
openconnect[4544]: Попытка подключения к серверу <ip address>:443
openconnect[4544]: SSL согласование с <правильно идентифицированный vpn сервер>
openconnect[4544]: Подключено к HTTPS на <правильно идентифицированный vpn сервер>
openconnect[4544]: Получен ответ CONNECT: HTTP/1.1 200 OK
openconnect[4544]: CSTP подключен. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN-соединение '<connection name>' (Получение конфигурации IP) получен ответ.
NetworkManager[784]: <info> VPN-соединение '<connection name>' (Получение конфигурации IP4) получен ответ.
NetworkManager[784]: <info> VPN-соединение '<connection name>' (Получение конфигурации IP6) получен ответ.
NetworkManager[784]: <info> VPN-шлюз: <ip address>
NetworkManager[784]: <info> Устройство туннеля: vpn0
NetworkManager[784]: <info> Конфигурация IPv4:
NetworkManager[784]: <info>   Внутренний адрес: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Внутренний префикс: 19
NetworkManager[784]: <info>   Внутренний адрес точки-точки: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Максимальный размер сегмента (MSS): 0
NetworkManager[784]: <info>   Запретить маршрут по умолчанию: нет
NetworkManager[784]: <info>   Внутренний DNS: <ip address>
NetworkManager[784]: <info>   Внутренний DNS: <ip address>
NetworkManager[784]: <info>   DNS-домен: '(нет)'
NetworkManager[784]: <info> Конфигурация IPv6:
NetworkManager[784]: <info>   Внутренний адрес: <ipv6 ip>
NetworkManager[784]: <info>   Внутренний префикс: 64
NetworkManager[784]: <info>   Внутренний адрес точки-точки: <ipv6 ip>
NetworkManager[784]: <info>   Максимальный размер сегмента (MSS): 0
NetworkManager[784]: <info>   Запретить маршрут по умолчанию: нет
NetworkManager[784]: <info>   DNS-домен: '(нет)'
openconnect[4544]: Подключено vpn0 как <ip address> + <ipv6 ip>, используя SSL
openconnect[4544]: Установлено DTLS-соединение (с использованием OpenSSL)
NetworkManager[784]: <info> VPN-соединение '<connection name>' (Получение конфигурации IP) завершено.
NetworkManager[784]: <info> Политика установлена '<connection name>' (vpn0) по умолчанию для маршрутизации IPv4 и DNS.
NetworkManager[784]: <info> Политика установлена '<connection name>' (vpn0) по умолчанию для маршрутизации IPv6 и DNS.
NetworkManager[784]: <info> Запись информации DNS в /sbin/resolvconf
dnsmasq[1027]: установка серверов верхнего уровня из DBus
dnsmasq[1027]: использование сервера имен 127.0.0.1#53 для домена 10.in-addr.arpa
dnsmasq[1027]: использование сервера имен 127.0.0.1#53 для домена <домашний домен поиска>
dnsmasq[1027]: использование сервера имен 127.0.0.1#53 для домена <домашний домен поиска>
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена 10.in-addr.arpa
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена <домашний домен поиска>
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена <домашний домен поиска>
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена 10.in-addr.arpa
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена <домашний домен поиска>
dnsmasq[1027]: использование сервера имен <ip address>#53 для домена <домашний домен поиска>
dbus[471]: [system] Активирование сервиса с именем="org.freedesktop.nm_dispatcher" (с использованием servicehelper)
NetworkManager[784]: <info> Состояние VPN-плагина изменено: начато (4)
NetworkManager[784]:    keyfile: обновление /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Служба 'org.freedesktop.nm_dispatcher' успешно активирована

Несмотря на весь шум в журнале об обновлении resolv.conf, он удаляет серверы имен, но не заменяет их на IP-адреса из лога. Тем не менее, он обновляет домен поиска правильно, поэтому это вероятно не проблема с правами доступа.

Журнал при подключении с использованием sudo openconnect в терминале:

NetworkManager[784]:    SCPlugin-Ifupdown: устройства добавлены (путь: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: устройство добавлено (путь: /sys/devices/virtual/net/tun0, iface: tun0): конфигурация ifupdown не найдена.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: не удалось определить драйвер устройства; игнорируем...
dbus[471]: [system] Активирование сервиса с именем="org.freedesktop.hostname1" (с использованием servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Предупреждение: nss-myhostname не установлен. Изменение локального имени хоста может сделать его нерешаемым. Пожалуйста, установите nss-myhostname!
dbus[471]: [system] Служба 'org.freedesktop.hostname1' успешно активирована

Нет ничего об обновлении resolv.conf, и тем не менее он правильно обновляет серверы имен и домен поиска.

Обновление
Если я игнорирую все предупреждения в resolv.conf и добавляю серверы имен vpn-концентратора, я мгновенно получаю доступ к интернету. Конечно, как только я отключаюсь, эти изменения перекрываются.

была ошибка по этому поводу, в 2012 году, но она истекла. Проблема, похоже, заключается в vpnc-скрипте.

Я попытался вручную обновить свои vpnc-скрипты до последних версий, но безуспешно.

Некоторые дальнейшие исследования показали, что начиная с 12.04 resolv.conf больше не то место, куда попадают серверы имен для разрешения DNS при использовании network-manager. Именно поэтому это работает, когда я использую командную строку, но не работает при использовании network-manager. Вместо этого сервер имен 127.0.1.1 [dnsmasq] добавляется, и этому серверу имен сообщают IP-адреса фактических серверов имен.

Большое преимущество состоит в том, что если вы подключаетесь к VPN, вместо того чтобы весь ваш DNS-трафик направлялся через VPN, как это было раньше, вы будете отправлять DNS-запросы, связанные только с подсетью и доменами, объявленными этим VPN.

Обновление
Отключение dnsmasq, как объясняется в приведённой выше ссылке, решает проблему, потому что /etc/resolv.conf заполняется.

Это не является реальным решением, это обходной путь.

Проверьте, есть ли несоответствие между хостом, который вы пытаетесь разрешить через VPN, и “DNS-доменом”, который отправляет сервер Cisco VPN.

Чтобы проверить это, откройте терминал и выполните:

tail -f /var/log/syslog

Затем запустите openconnect через network manager. Вы увидите целый ряд выводов, включая такие строки:

5 дек 12:54:31 canoe NetworkManager[1266]: Внутренний DNS: 10.0.20.21

5 дек 12:54:31 canoe NetworkManager[1266]: Внутренний DNS: 10.10.3.32

5 дек 12:54:31 canoe NetworkManager[1266]: DNS-домен: ‘internal.example.com’

А дальше вы увидите

5 дек 12:54:31 canoe dnsmasq[1871]: использование сервера имен 10.0.20.21#53 для домена internal.example.com

Это означает, что сервер VPN инструктирует клиент использовать DNS-серверы для разрешения хостов в internal.example.com, таких как server.internal.example.com.

В моем случае мне нужно было разрешить server.example.com (и я не получал никакого результата).

Решением для меня было зайти в настройки VPN и добавить example.com в качестве дополнительного домена поиска:

Не забудьте отключить VPN, а затем снова подключиться, чтобы настройки вступили в силу.

Таким образом, я удовлетворительно решил эту проблему для себя. Я использую Mint 18 / Ubuntu 16.04

Моя проблема заключалась в том, что как только я подключался к Openconnect VPN через NetworkManager, я больше не мог разрешить DNS для доменов вне моих рабочих доменов. То есть, я потерял интернет!

Мое решение было следующим:

1. В NetworkManager я отредактировал VPN-соединение в разделе “Сетевые подключения”.
2. На вкладке IPv4 я сменил метод на “Автоматические (VPN) адреса только”
3. Добавил свой рабочий DNS-сервер (например, 10.10.10.100) и “Домен поиска” “mywork.tld”
4. Нажал на “Маршруты”.
5. Добавил маршрут, который охватывает мою рабочую сеть, например, 10.10.0.0 / 255.255.0.0 и шлюз 10.10.10.253 <– шлюз VPN, который я получил из “traceroute”.
6. Затем я отметил оба варианта:
   i. “Игнорировать автоматически полученные маршруты”
   ii. “Использовать это соединение только для ресурсов в своей сети”

Работает на моем компьютере.

Мое понимание того, что произошло, таково:

1. Мой /etc/resolv.conf настроен с dnsmasq и указывает на 127.0.1.1
2. dnsmasq использует DNS-серверы моего провайдера для общего разрешения DNS в интернете. Например, DNS провайдера, скажем, 8.8.8.8.
3. Я подключаюсь к VPN, DNS-сервер 10.10.10.100 добавляется как дополнительный сервер для разрешения DNS “mywork.tld”.
4. Как только я нахожусь в VPN, мой рабочий брандмауэр больше не позволяет мне использовать порт 53 для 8.8.8.8, поэтому разрешение для общего интернета пропадает. DNS должен истечь и перейти на вторичный DNS-сервер, но по какой-то причине этого не происходит?
5. У меня остается доступ только к разрешению DNS для “server01.mywork.tld”, потому что этот запрос переходит на 10.10.10.100, к которому я имею доступ через VPN.
6. Если я запрашиваю www.google.com, он не проходит, хотя мой внутренний DNS может пересылать. Я могу только предполагать, что мой внутренний DNS никогда не запрашивается.

Мое решение, похоже, продолжает работать, пока моя работа не изменит свою сеть или IP-адрес DNS-сервера.

Я немного запутался, но думаю, это работает для меня, потому что как только это сделано, моя беспроводная сетевая карта становится моим соединением по умолчанию. Так что DNS-запросы идут на 8.8.8.8 по Wi-Fi. Любой запрос на “xyz.mywork.tld” направляется dnsmasq на 10.10.10.100. Я установил маршрут для этого, так что он проходит через NIC “vpn0”, который возвращает правильный IP-адрес 10.10.10.x для “xyz.mywork.tld”. Бинго, бинго, разрешение DNS для внутренних и внешних сетей, и все счастливы.