отримання openconnect vpn для роботи через мережевий менеджер

це те саме питання, що і тут: Здійснення openconnect vpn для роботи через gui , але мої доповнення до нього були видалені, і мене попросили створити нове запитання.

насправді, тут є декілька людей, які задають подібні запитання, всі з 0 відповідями.

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

головне питання: я намагаюся додати vpn-з'єднання до мережевого менеджера, використовуючи openconnect. коли я надаю своє vpn ім'я користувача та пароль, він успішно підключається, але я не можу вирішити dns.

якщо я запускаю openconnect в терміналі через sudo, dns працює.

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

Детальніше:

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

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

2а. при підключенні через openconnect та мережевий менеджер створюється новий інтерфейс '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'

незважаючи на весь шум у журналі з приводу оновлення resolutionv.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'

нічого не стосується оновлення reslav.conf, але воно належним чином оновлює сервери імен та пошуковий домен.

оновіть, якщо я ігнорую всі попередження у resoluv.conf і додаю до нього сервери імен концентратора vpn, я зараз можу переглядати. звичайно, як тільки я відключаюсь, ці зміни перезаписуються.

Помилка про це була ще в 2012 році, але термін її дії закінчився. видається, що це сценарій vpnc.

Я намагався оновити свої vpnc-скрипти вручну до останніх версій, але безрезультатно.

Деякі подальші дослідження виявляють, що станом на 12.04 разрешення.conf вже не туди, де сервери імен ідуть на вирішення dns при використанні мережевого менеджера. ось чому він працює, коли я використовую командний рядок, але не під час використання мережевого менеджера. скоріше додається сервер імен 127.0.1.1 [dnsmasq], і цьому серверу імен повідомляються ip адреси фактичних серверів імен.

Велика перевага полягає в тому, що якщо ви підключаєтесь до VPN, замість того, щоб весь ваш DNS-трафік був спрямований через VPN, як і раніше, ви натомість надсилаєте лише запити DNS, пов’язані з підмережею та доменами, оголошеними цією VPN

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

це не справжнє рішення, хоча це резервний запас.

— zee
джерело

Чому 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? Місцеві назви? Будь ласка, опублікуйте фактичний вміст resl.conf, який, на вашу думку, не оновлюється належним чином. Чи знаєте ви, що NetworkManager за замовчуванням запускає сервер імен перенаправлення - екземпляр dnsmasq - який прослуховує 127.0.1.1 і пересилає запити до серверів імен за адресами, які йому надає NetworkManager через DBus? Коли використовується цей сервер імен переадресації, у nameserverрядку в /etc/resolv.conf вказана лише його адреса прослуховування , незалежно від того, скільки серверів імен forwardee використовується.

— jdthood

Перевірте, чи є невідповідність між хостом, який ви намагаєтеся вирішити через VPN, та "DNS-доменом", який надсилає сервер VPN Cisco.

Щоб перевірити це, відкрийте термінал і запустіть:

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 Domain: '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
джерело

Тому я вирішив це для себе досить задовільно. Я на Монетному дворі 18 / Ubuntu 16.04

Моя проблема полягала в тому, що після підключення до VPN Openconnect через 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".
Тоді я позначив обидва варіанти: i. "Ігнорувати автоматично налаштовані маршрути" ii. "Використовувати це з'єднання лише для ресурсів у його мережі"

Працює на моєму комп’ютері.

Я розумію, що сталося, це те, що:

Мій /etc/resolv.conf встановлюється за допомогою dnsmasq і вказує на 127.0.1.1
dnsmasq використовує DNS-сервери мого провайдера для загальної роздільної здатності DNS в Інтернеті. Наприклад, ISP 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-сервера.

Я трохи туманний щодо цього, але я думаю, що це працює для мене, оскільки після цього моє мережеве з'єднання Wireless Wireless стане моїм мережевим з'єднанням за замовчуванням. Тож запити DNS переходять на 8.8.8.8 через wifi. Будь-який запит на "xyz.mywork.tld" відповідає dnsmasq, щоб перейти до 10.10.10.100. Я встановив маршрут для цього, так що він переходить через NIC "vpn0", який повертає правильну IP-адресу 10.10.10.x для "xyz.mywork.tld". Роздільна здатність DNS для Bingo bango для внутрішніх і зовнішніх мереж і всі раді.

— Шеньчан
джерело