☰

Заставляем openconnect vpn работать через network-manager

tag-icon • tag-icon network-manager vpn dns resolv.conf cisco
Заставляем openconnect vpn работать через network-manager

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

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

Версии программного обеспечения: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-скрипту. Должно быть, он получает ее от VPN-концентратора. [журнал также ниже]

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

2б. При подключении через 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. Вот почему это работает, когда я использую командную строку, но не при использовании network-manager. Вместо этого добавляется сервер имен 127.0.1.1 [dnsmasq] и этому серверу имен сообщаются IP-адреса фактических серверов имен.

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

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

Но это не настоящее решение, а запасной вариант.

решение1

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

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

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

введите описание изображения здесь

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

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

Связанный контент