conseguir que openconnect vpn funcione a través del administrador de red

10

este es el mismo problema que aquí: hacer que openconnect vpn funcione a través de la interfaz gráfica de usuario , pero mis adiciones se eliminaron y me pidieron que creara una nueva pregunta.

de hecho, hay varias personas que hacen preguntas similares aquí, todas con 0 respuestas.

versiones de software: ubuntu 14.04, openconnect 5.02

problema principal: estoy tratando de agregar una conexión vpn al administrador de red, usando openconnect. Cuando proporciono mi nombre de usuario y contraseña de VPN, se conecta correctamente, pero no puedo resolver DNS.

si ejecuto openconnect en la terminal a través de sudo, dns funciona.

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

más detalles:

1a. cuando me conecto a través de openconnect y network-manager a pesar de que he agregado explícitamente dns y un dominio de búsqueda en la pestaña ipv4, solo el dominio de búsqueda termina en /etc/resolv.conf. incluso si no proporciono dns y busca dominios, puedo ver en los registros que está obteniendo esa información del concentrador vpn. nuevamente, el dominio de búsqueda se actualiza correctamente. [iniciar sesión a continuación]

1b. cuando se conecta a través de sudo en una terminal, resolv.conf se rellena correctamente con dns y dominios de búsqueda aunque no haya agregado esa información en la línea de comando o haya proporcionado una ruta a un script vpnc. debe obtenerlo del concentrador vpn. [log también debajo]

2a. cuando se conecta a través de openconnect y network-manager, se crea una nueva interfaz 'vpn0'.

2b. cuando se conecta a través de sudo y línea de comando, se crea una nueva interfaz 'tun0'.

iniciar sesión al conectarse a través del administrador de red:

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)

aquí es donde me pide mi contraseña

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'

a pesar de todo el ruido en el registro sobre la actualización de resolv.conf, elimina los servidores de nombres pero no los reemplaza con las direcciones IP en el registro. actualiza el dominio de búsqueda correctamente, por lo que probablemente no sea un problema de permisos.

iniciar sesión al conectar usando sudo openconnect en la terminal:

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'

nada acerca de actualizar resolv.conf y, sin embargo, actualiza correctamente los servidores de nombres y el dominio de búsqueda.

actualizar si ignoro todas las advertencias en resolv.conf y le agrego los servidores de nombres del concentrador vpn, puedo navegar instantáneamente. Por supuesto, tan pronto como me desconecto, esos cambios se sobrescriben.

hubo un error en esto , en 2012, pero expiró. El problema parece ser el script vpnc.

Traté de actualizar manualmente mis scripts vpnc a las últimas versiones, pero fue en vano.

cierta investigación adicional revela que a partir del 12.04 resolv.conf ya no es donde los servidores de nombres van para la resolución dns cuando se usa network-manager. por eso funciona cuando uso la línea de comando, pero no cuando uso el administrador de red. más bien se agrega el servidor de nombres 127.0.1.1 [dnsmasq] y se le dice a ese servidor de nombres las direcciones IP de los servidores de nombres reales.

La gran ventaja es que si se conecta a una VPN, en lugar de que todo su tráfico DNS se enrute a través de la VPN como en el pasado, solo enviará consultas DNS relacionadas con la subred y los dominios anunciados por esa VPN

La actualización de la desactivación de dnsmasq como se explica en el enlace anterior resuelve el problema porque /etc/resolv.conf está lleno.

Esta no es una solución real, aunque es una alternativa.

network-manager vpn dns resolv.conf cisco zee
fuente
¿Por qué NetworkManager enumera 127.0.0.1 además de las otras dos direcciones IP eliminadas? ¿Qué servidor de nombres se ejecuta localmente y escucha en 127.0.0.1 y es capaz de resolver nombres de VPN?
jdthood
Creo que eso es solo para el almacenamiento en caché de DNS. no es un servidor de nombres "real".
zee
La dirección 127.0.0.1 aparece como una dirección de servidor de nombres obtenida por NetworkManager. NetworkManager pasa esta dirección a dnsmasq para usarla como dirección de reenvío. Dnsmasq intentará reenviar consultas a esta dirección, que es una dirección de bucle invertido. ¿Existe realmente un servidor de nombres ejecutándose en la máquina local que escucha las consultas en esa dirección? E incluso si es así, ¿por qué NetworkManager informa la dirección durante el inicio de la VPN? Me parece que su servidor VPN está mal configurado para proporcionar 127.0.0.1 como una dirección de servidor de nombres en la VPN.
jdthood
Curiosamente, cuando probé mi conexión esta mañana, esa línea ya no está, así que son solo los servidores de 2 dns del concentrador.
zee
¿Y ahora puedes resolver los nombres de Internet? Nombres de VPN? Nombres locales? Publique el contenido real de resolv.conf que dice que no se actualiza correctamente. ¿Sabía que NetworkManager ejecuta de manera predeterminada un servidor de nombres de reenvío, una instancia de dnsmasq, que escucha en 127.0.1.1 y reenvía consultas a los servidores de nombres en las direcciones que le proporciona NetworkManager a través de DBus? Cuando se utiliza este servidor de nombres de reenvío, solo su dirección de escucha aparece en una nameserverlínea en /etc/resolv.conf, independientemente de cuántos servidores de nombres de reenvío estén en uso.
jdthood

Respuestas:

0

Compruebe si hay una falta de coincidencia entre el host que está tratando de resolver a través de la VPN y el "Dominio DNS" que está enviando el servidor VPN de Cisco.

Para verificar esto, abra una terminal y ejecute:

tail -f /var/log/syslog

Luego, inicie openconnect a través del administrador de red. Verá un montón de resultados, incluidas algunas líneas como esta:

5 de diciembre 12:54:31 NetworkManager en canoa [1266]: DNS interno: 10.0.20.21

5 de diciembre 12:54:31 NetworkManager canoa [1266]: DNS interno: 10.10.3.32

5 de diciembre 12:54:31 NetworkManager canoa [1266]: Dominio DNS: 'internal.example.com'

Y más abajo verás

5 de diciembre 12:54:31 canoa dnsmasq [1871]: uso del servidor de nombres 10.0.20.21 # 53 para el dominio internal.example.com

Esto significa que el servidor VPN le está indicando al cliente que los servidores DNS deben usarse para resolver hosts dentro internal.example.com, como por ejemplo server.internal.example.com.

En mi caso, necesito resolver server.example.com(y no estaba obteniendo ningún resultado).

La solución para mí fue ir a la configuración de VPN y agregar example.comcomo un dominio de búsqueda adicional:

ingrese la descripción de la imagen aquí

No olvide desconectar la VPN y luego volver a conectarse para que la configuración surta efecto.

jdhildeb
fuente
0

Así que he resuelto esto por mí mismo de manera satisfactoria. Estoy en Mint 18 / Ubuntu 16.04

Mi problema fue que una vez que me conecté a Openconnect VPN a través de NetworkManager ya no podía resolver DNS para dominios fuera de mis dominios de trabajo. Es decir, perdí internet!

Mi solución fue esta:

  1. En NetworkManager, edité la conexión VPN en "Conexiones de red".
  2. En la pestaña IPv4, el método cambió a "Solo direcciones automáticas (VPN)"
  3. Agregué el servidor DNS de mi trabajo (por ejemplo, 10.10.10.100) y "Buscar dominio" de "mywork.tld"
  4. Haga clic en "Rutas".
  5. Agregue una ruta que cubra mi red de trabajo, por ejemplo, 10.10.0.0 / 255.255.0.0 y la puerta de enlace de 10.10.10.253 <- Puerta de enlace VPN que obtuve de un "traceroute".
  6. Luego marqué ambas opciones: i. "Ignorar rutas seleccionadas automáticamente" ii. "Utilice esta conexión solo para recursos en su red"

Funciona en mi computadora.

Entiendo lo que sucedió es que:

  1. Mi /etc/resolv.conf está configurado con dnsmasq y apunta a 127.0.1.1
  2. dnsmasq está utilizando los servidores DNS de mi ISP para la resolución general de DNS de Internet. Por ejemplo, ISP DNS es digamos 8.8.8.8.
  3. Me conecto a VPN, el servidor DNS de 10.10.10.100 se agrega como un servidor adicional a dnsmasq para ser utilizado para la resolución DNS "mywork.tld".
  4. Una vez que estoy en la VPN, mi firewall de trabajo ya no me permite usar el puerto 53 a 8.8.8.8, por lo que mi resolución general de Internet desaparece. El DNS debe agotar el tiempo de espera e ir al servidor DNS secundario, pero ¿no es así por alguna razón?
  5. Solo me queda acceso a la resolución DNS para "server01.mywork.tld" porque esta consulta va a 10.10.10.100 a la que tengo acceso a través de la VPN.
  6. Si consulto www.google.com, falla, aunque mi DNS interno puede reenviar. Solo puedo suponer que mi DNS interno nunca se solicita.

Parece que mi solución sigue funcionando mientras mi trabajo no cambie su red o la dirección IP del servidor DNS.

Estoy un poco confuso al respecto, pero creo que funciona para mí porque una vez hecho esto, mi NIC inalámbrica se convierte en mi conexión de red predeterminada. Entonces las consultas DNS van a 8.8.8.8 a través de wifi. Dnsmasq le dice a cualquier consulta para "xyz.mywork.tld" que vaya a 10.10.10.100. He establecido una ruta para eso, por lo que pasa sobre la NIC "vpn0" que devuelve la dirección IP 10.10.10.x correcta para "xyz.mywork.tld". Bingo bango resolución DNS para redes internas y externas y todos están contentos.

Seanchán
fuente