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 se me pidió 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, conexión abierta 5.02
Tema principal:Estoy intentando 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 mediante 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, aunque agregué 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 ni dominios de búsqueda, puedo ver en los registros que obtiene esa información del concentrador VPN. Nuevamente, el dominio de búsqueda se actualiza correctamente. [iniciar sesión a continuación]
1b. Al conectarse a través de sudo en una terminal, resolv.conf se completa correctamente con DNS y dominios de búsqueda, aunque no agregué esa información en la línea de comando ni proporcioné una ruta a un script vpnc. Debe obtenerlo del concentrador VPN. [registrar también a continuación]
2a. Al conectarse a través de openconnect y network-manager, se crea una nueva interfaz 'vpn0'.
2b. Al conectarse mediante 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 es probablenoun problema de permisos.
Inicia sesión al conectarte usando sudo openconnect en una 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 sobre 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, allá por 2012, pero expiró. El problema parece ser el script vpnc.
Intenté actualizar manualmente mis scripts vpnc a las últimas versiones, pero fue en vano.
Algunomás investigaciónResulta que a partir del 12.04 resolv.conf ya no es el lugar al que van los servidores de nombres para la resolución dns cuando se usa el administrador de red. 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 a ese servidor de nombres se le indican 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.
Actualizar Deshabilitar dnsmasq como se explica en el enlace anterior resuelve el problema porque /etc/resolv.conf está completo.
Sin embargo, esta no es una solución real, es una alternativa.
Respuesta1
Verifique si hay una discrepancia entre el host que está intentando resolver a través de la VPN y el "Dominio DNS" que envía 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á una gran cantidad de resultados, incluidas algunas líneas como esta:
5 de diciembre 12:54:31 canoa NetworkManager[1266]: DNS interno: 10.0.20.21
5 de diciembre 12:54:31 canoa NetworkManager[1266]: DNS interno: 10.10.3.32
5 de diciembre 12:54:31 canoa NetworkManager[1266]: Dominio DNS: 'internal.example.com'
Y más abajo verás
5 de diciembre 12:54:31 canoa dnsmasq[1871]: usando el servidor de nombres 10.0.20.21#53 para el dominio internal.example.com
Esto significa que el servidor VPN está indicando al cliente que los servidores DNS deben usarse para resolver hosts dentro de internal.example.com, como por ejemplo server.internal.example.com.
En mi caso, necesito resolverlo server.example.com(y no obtuve ningún resultado).
La solución para mí fue ingresar a la configuración de VPN y agregar example.comcomo dominio de búsqueda adicional:
No olvide desconectar la VPN y luego volver a conectarse para que la configuración surta efecto.
Respuesta2
Así que lo he resuelto bastante satisfactoriamente. 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 pude resolver DNS para dominios fuera de mis dominios de trabajo. Es decir, ¡perdí Internet!
Mi solución fue esta:
- En NetworkManager, edité la conexión VPN en "Conexiones de red".
- En la pestaña IPv4, se cambió el método a "Solo direcciones automáticas (VPN)"
- Agregué el servidor DNS de mi trabajo (por ejemplo, 10.10.10.100) y el "dominio de búsqueda" de "mywork.tld".
- Haga clic en "Rutas".
- Agregue una ruta que cubra mi red de trabajo, por ejemplo, 10.10.0.0 / 255.255.0.0 y la puerta de enlace 10.10.10.253 <-- La puerta de enlace VPN que obtuve de una "traceroute".
- Luego marqué ambas opciones: i. "Ignorar rutas seleccionadas automáticamente" ii. "Utilice esta conexión sólo para recursos en su red"
Funciona en mi computadora.
Mi comprensión de lo que pasó es que:
- Mi /etc/resolv.conf está configurado con dnsmasq y apunta a 127.0.1.1
- dnsmasq está utilizando los servidores DNS de mi ISP para la resolución general de DNS de Internet. Por ejemplo, el DNS del ISP es, digamos, 8.8.8.8.
- Me conecto a una VPN, el servidor DNS 10.10.10.100 se agrega como servidor adicional a dnsmasq para usarse para la resolución DNS de "mywork.tld".
- Una vez que estoy en la VPN, el firewall de mi trabajo ya no me permite usar el puerto 53 al 8.8.8.8, por lo que mi resolución general de Internet desaparece. ¿El DNS debería agotar el tiempo de espera e ir al servidor DNS secundario, pero no es así por alguna razón?
- Solo me queda acceso a la resolución DNS para "server01.mywork.tld" porque esta consulta va a 10.10.10.100, al que tengo acceso a través de la VPN.
- Si consulto www.google.com, falla, aunque mi DNS interno puede reenviar. Sólo puedo asumir que nunca se solicita mi DNS interno.
Mi solución parece seguir funcionando siempre que 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 de DNS van a 8.8.8.8 a través de wifi. dnsmasq le indica a cualquier consulta de "xyz.mywork.tld" que vaya a 10.10.10.100. He establecido una ruta para eso, de modo que pasa por la NIC "vpn0" que devuelve la dirección IP 10.10.10.x correcta para "xyz.mywork.tld". Resolución DNS de Bingo bango para redes internas y externas y todos están contentos.