Вопросы Теги

получение openconnect vpn для работы через администратора сети

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

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

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

основной вопрос: я пытаюсь добавить соединение VPN в администратора сети, с помощью openconnect., когда я предоставляю свое vpn имя пользователя и пароль, оно соединяется успешно, но я не могу разрешить DNS.

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

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

подробнее:

1a. при соединении через openconnect и администратора сети даже при том, что я явно добавил DNS и область поиска под ipv4 вкладкой, только область поиска заканчивается в/etc/resolv.conf., даже если я не предоставляю DNS и области поиска, я вижу в журналах, что это получает ту информацию от vpn концентратора. снова, область поиска обновляется правильно. [журнал ниже]

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

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

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

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

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

8
задан 13 April 2017 в 15:23

2 ответа

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

Для проверки на это откройте терминал и работайте:

tail -f /var/log/syslog

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

5 декабря 12:54:31 плывет на каноэ NetworkManager[1266]: Внутренний DNS: 10.0.20.21

5 декабря 12:54:31 плывет на каноэ NetworkManager[1266]: Внутренний DNS: 10.10.3.32

5 декабря 12:54:31 плывет на каноэ NetworkManager[1266]: Домен DNS: 'internal.example.com'

И далее вниз Вы будете видеть

5 декабря 12:54:31 плывет на каноэ 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 как дополнительная область поиска:

enter image description here

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

0
ответ дан 14 April 2017 в 01:23

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

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

Моя фиксация была этим:

  1. В NetworkManager, я отредактировал соединение VPN при "Сетевых соединениях".
  2. На вкладке IPv4, измененном методе для "Автоматического (VPN) Адреса Только"
  3. Добавленный моя работа сервер DNS (например, 10.10.10.100) и "Область поиска" "mywork.tld"
  4. Нажимает на "Routes".
  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 моего ISP для общего интернет-разрешения DNS. Например, ISP DNS скажем, 8.8.8.8.
  3. я соединяюсь с VPN, сервер DNS 10.10.10.100 добавляется как дополнительный сервер к dnsmasq, который будет использоваться для "mywork.tld" разрешения DNS.
  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.

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

0
ответ дан 14 April 2017 в 01:23
  • 1
    I' m не уверенный, когда я нахожу, что время обновляет до 16,04 и затем вручную обновляет ядро до 4.7.2 или позже. Но I' ll дают ему попытку в конечном счете. Однако, I' d радоваться, было ли другое решение, которое работает над моей системой (14.04) также. – Klamann 6 September 2016 в 00:20

Другие вопросы по тегам:

Похожие вопросы: