заставить openconnect vpn работать через network-manager

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

На самом деле, есть много людей, которые задают подобные вопросы здесь, все с 0 ответами.

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

Основная проблема: я пытаюсь добавить vpn-соединение в сетевой менеджер, используя 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. опять же, поисковый домен обновляется правильно. [войти ниже]

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

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

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

войти при подключении через сеть-менеджер:

NetworkManager[784]: <info> Starting VPN service 'openconnect'...
NetworkManager[784]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN service 'openconnect' appeared; activating connections
NetworkManager[784]: <info> VPN plugin state changed: init (1)

это где он просит мой пароль

NetworkManager[784]: <info> VPN plugin state changed: starting (3)
NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/vpn0, iface: vpn0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: couldn't determine device driver; ignoring...
NetworkManager[784]: <info> VPN connection '<connection name>' (Connect) reply received.
openconnect[4544]: Attempting to connect to server <ip address>:443
openconnect[4544]: SSL negotiation with <correctly identified vpn server>
openconnect[4544]: Connected to HTTPS on <correctly identified vpn server>
openconnect[4544]: Got CONNECT response: HTTP/1.1 200 OK
openconnect[4544]: CSTP connected. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP4 Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP6 Config Get) reply received.
NetworkManager[784]: <info> VPN Gateway: <ip address>
NetworkManager[784]: <info> Tunnel Device: vpn0
NetworkManager[784]: <info> IPv4 configuration:
NetworkManager[784]: <info>   Internal Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Internal Prefix: 19
NetworkManager[784]: <info>   Internal Point-to-Point Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   DNS Domain: '(none)'
NetworkManager[784]: <info> IPv6 configuration:
NetworkManager[784]: <info>   Internal Address: <ipv6 ip>
NetworkManager[784]: <info>   Internal Prefix: 64
NetworkManager[784]: <info>   Internal Point-to-Point Address: <ipv6 ip>
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   DNS Domain: '(none)'
openconnect[4544]: Connected vpn0 as <ip address> + <ipv6 ip>, using SSL
openconnect[4544]: Established DTLS connection (using OpenSSL)
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) complete.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv4 routing and DNS.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[784]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1027]: setting upstream servers from DBus
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <home search domain>
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dbus[471]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
NetworkManager[784]: <info> VPN plugin state changed: started (4)
NetworkManager[784]:    keyfile: updating /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

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

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

NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
dbus[471]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
dbus[471]: [system] Successfully activated service 'org.freedesktop.hostname1'

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

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

В 2012 году была ошибка , но срок ее действия истек. проблема, кажется, сценарий vpnc.

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

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

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

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

это не реальное решение, хотя это запасной вариант.

— зет
источник

Почему NetworkManager перечисляет 127.0.0.1 в дополнение к двум другим отредактированным IP-адресам? Какой сервер имен работает локально и прослушивает 127.0.0.1 и может разрешать имена VPN?

— Jdthood

Я думаю, что это только для DNS-кэширования. это не "настоящий" сервер имен.

— Zee

Адрес 127.0.0.1 указан как адрес сервера имен, полученный NetworkManager. NetworkManager передает этот адрес в dnsmasq для использования в качестве адреса пересылки. Dnsmasq попытается переслать запросы на этот адрес, который является адресом обратной связи. На самом ли деле на локальном компьютере работает сервер имен, который прослушивает запросы по этому адресу? И даже если так, почему NetworkManager сообщает адрес во время инициализации VPN? Мне кажется, что ваш VPN-сервер неправильно настроен для предоставления 127.0.0.1 в качестве адреса сервера имен в VPN.

— Jdthood

Интересно, что когда я попробовал мое соединение этим утром, эта линия теперь пропала, так что это всего лишь 2 DNS-сервера от концентратора.

— Zee

И можете ли вы теперь разрешить интернет-имена? VPN-имена? Местные имена? Пожалуйста, опубликуйте фактическое содержимое resolv.conf, которое, по вашему мнению, не обновляется должным образом. Знаете ли вы, что NetworkManager по умолчанию запускает сервер имен переадресации - экземпляр dnsmasq - который прослушивает 127.0.1.1 и перенаправляет запросы на серверы имен по адресам, переданным ему NetworkManager через DBus? Когда используется этот перенаправляющий сервер имен, в nameserverстроке /etc/resolv.conf указывается только его адрес прослушивания , независимо от того, сколько серверов имен forwardee используется.

— Jdthood

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

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

tail -f /var/log/syslog

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

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, а затем снова подключиться, чтобы настройки вступили в силу.

— jdhildeb
источник

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

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

Мое исправление было таким:

В NetworkManager я редактировал VPN-соединение в разделе «Сетевые подключения».
На вкладке IPv4 изменился метод на «Только автоматические (VPN) адреса»
Добавлен мой рабочий DNS-сервер (например, 10.10.10.100) и «Поиск домена» из «mywork.tld»
Нажмите на «Маршруты».
Добавьте маршрут, который покрывает мою рабочую сеть, например, 10.10.0.0 / 255.255.0.0 и шлюз 10.10.10.253 <- шлюз VPN, полученный из «traceroute».
Затем я выбрал оба варианта: я. «Игнорировать автоматически открытые маршруты» ii. «Используйте это соединение только для ресурсов в своей сети»

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

Я понимаю, что случилось так:

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

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

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

— Шончане
источник