Заставить 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.

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

Источник

2 ответа

Так что я решил это для себя достаточно удовлетворительно. Я на 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. Затем я поставил галочку в обоих вариантах: "Игнорировать автоматически открытые маршруты" 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 добавлен в качестве дополнительного сервера к dnsmasq, который будет использоваться для разрешения 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. Dnsmasq сообщает, что любой запрос для "xyz.mywork.tld" должен перейти к 10.10.10.100. Я установил для этого маршрут, чтобы он проходил через сетевой адаптер "vpn0", который возвращает правильный IP-адрес 10.10.10.x для "xyz.mywork.tld". Разрешение Бинго Банго DNS для внутренних и внешних сетей, и все счастливы.

Источник

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

Источник
Другие вопросы по тегам