NetworkManager no cambia /etc/resolv.conf después de openvpn dns push


22

Tengo un problema que es "NetworkManager no se actualiza /etc/resolv.confdespués de la conexión openvpn con dns push configurado".

Aquí está la configuración de mi servidor openvpn: ( he cambiado el nombre de dominio a ABC.COM por razones de seguridad;) )

########################################
# Sample OpenVPN config file for
# 2.0-style multi-client udp server
#
# Adapted from http://openvpn.sourceforge.net/20notes.html
#
# tun-style tunnel

port 1194
dev tun

# Use "local" to set the source address on multi-homed hosts
#local [IP address]

# TLS parms
tls-server 
ca keys/ca.crt
cert keys/static.crt
key keys/static.key
dh keys/dh1024.pem
proto tcp-server

# Tell OpenVPN to be a multi-client udp server
mode server

# The server's virtual endpoints
ifconfig 10.8.0.1 10.8.0.2

# Pool of /30 subnets to be allocated to clients.
# When a client connects, an --ifconfig command
# will be automatically generated and pushed back to
# the client.
ifconfig-pool 10.8.0.4 10.8.0.255

# Push route to client to bind it to our local
# virtual endpoint.
push "route 10.8.0.1 255.255.255.255"

push "dhcp-option DNS 10.8.0.1"

# Push any routes the client needs to get in
# to the local network.
#push "route 192.168.0.0 255.255.255.0"

# Push DHCP options to Windows clients.
push "dhcp-option DOMAIN ABC.COM"
#push "dhcp-option DNS 192.168.0.1"
#push "dhcp-option WINS 192.168.0.1"

# Client should attempt reconnection on link
# failure.
keepalive 10 60

# Delete client instances after some period
# of inactivity.
inactive 600

# Route the --ifconfig pool range into the
# OpenVPN server.
route 10.8.0.0 255.255.255.0

# The server doesn't need privileges
user openvpn
group openvpn

# Keep TUN devices and keys open across restarts.
persist-tun
persist-key

verb 4

Como puede ver, es básicamente una configuración de muestra con poco ajuste.

Ahora..

En mi máquina (cliente openvpn), puedo ver que dns está bien:

{17:12}/etc/NetworkManager ➭ nslookup git.ABC.COM 10.8.0.1
Server:     10.8.0.1
Address:    10.8.0.1#53

Name:   git.ABC.COM
Address: 10.8.0.1

{17:18}/etc/NetworkManager ➭ nslookup ABC.COM 10.8.0.1   
Server:     10.8.0.1
Address:    10.8.0.1#53

Name:   ABC.COM
Address: 18X.XX.XX.71

Los registros de openvpn en el lado del servidor dicen (si entiendo correctamente) que el DNS ha sido enviado:

openvpn[13257]: TCPv4_SERVER link remote: [AF_INET]83.30.135.214:37658
openvpn[13257]: 83.30.135.214:37658 TLS: Initial packet from [AF_INET]83.30.135.214:37658, sid=3251df51 915772f3
openvpn[13257]: 83.30.135.214:37658 VERIFY OK: depth=1, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, emailAddress=mail@ABC.COM
openvpn[13257]: 83.30.135.214:37658 VERIFY OK: depth=0, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, emailAddress=mail@ABC.COM
openvpn[13257]: 83.30.135.214:37658 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[13257]: 83.30.135.214:37658 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[13257]: 83.30.135.214:37658 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[13257]: 83.30.135.214:37658 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[13257]: 83.30.135.214:37658 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
openvpn[13257]: 83.30.135.214:37658 [jacek] Peer Connection Initiated with [AF_INET]83.30.135.214:37658
openvpn[13257]: jacek/83.30.135.214:37658 MULTI_sva: pool returned IPv4=10.8.0.10, IPv6=(Not enabled)
openvpn[13257]: jacek/83.30.135.214:37658 MULTI: Learn: 10.8.0.10 -> jacek/83.30.135.214:37658
openvpn[13257]: jacek/83.30.135.214:37658 MULTI: primary virtual IP for jacek/83.30.135.214:37658: 10.8.0.10
openvpn[13257]: jacek/83.30.135.214:37658 PUSH: Received control message: 'PUSH_REQUEST'
openvpn[13257]: jacek/83.30.135.214:37658 send_push_reply(): safe_cap=940
openvpn[13257]: jacek/83.30.135.214:37658 SENT CONTROL [jacek]: 'PUSH_REPLY,route 10.8.0.1 255.255.255.255,dhcp-option DNS 10.8.0.1,dhcp-option DOMAIN ABC.COM,ping 10,ping-restart 60,ifconfig 10.8.0.10 10.8.0.9' (status=1)

OpenVP registra a mi lado:

Aug 05 17:13:55 localhost.localdomain openvpn[1198]: TCPv4_CLIENT link remote: [AF_INET]XXX.XX.37.71:1194
Aug 05 17:13:55 localhost.localdomain openvpn[1198]: TLS: Initial packet from [AF_INET]XXX.XX.37.71:1194, sid=89cc981c d57dd826
Aug 05 17:13:56 localhost.localdomain openvpn[1198]: VERIFY OK: depth=1, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, emailAddress=mail@ABC.COM
Aug 05 17:13:56 localhost.localdomain openvpn[1198]: VERIFY OK: depth=0, C=XX, ST=XX, L=XXX, O=XXX, OU=XXX, CN=XXX, name=XXX, emailAddress=mail@ABC.COM
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug 05 17:13:58 localhost.localdomain openvpn[1198]: [static] Peer Connection Initiated with [AF_INET]XXX.XX.37.71:1194
Aug 05 17:14:00 localhost.localdomain openvpn[1198]: SENT CONTROL [static]: 'PUSH_REQUEST' (status=1)
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1 255.255.255.255,dhcp-option DNS 10.8.0.1,dhcp-option DOMAIN ABC.COM,ping 10,ping-restart 60,ifconfig 10.8.0.10 10.8.0.9'
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: timers and/or timeouts modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: --ifconfig/up options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: route options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: ROUTE_GATEWAY 10.123.123.1/255.255.255.0 IFACE=wlan0 HWADDR=44:6d:57:32:81:2e
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: TUN/TAP device tun0 opened
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: TUN/TAP TX queue length set to 100
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip link set dev tun0 up mtu 1500
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip addr add dev tun0 local 10.8.0.10 peer 10.8.0.9
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: /usr/sbin/ip route add 10.8.0.1/32 via 10.8.0.9
Aug 05 17:14:01 localhost.localdomain openvpn[1198]: Initialization Sequence Completed

Parece que todo está bien.

Pero. También revisé /var/log/messages... y encontré esa línea:

Aug  5 17:14:01 localhost NetworkManager[761]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...

ip a devoluciones:

5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.0.10 peer 10.8.0.9/32 scope global tun0
       valid_lft forever preferred_lft forever

route -n devoluciones:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.123.123.1    0.0.0.0         UG    0      0        0 wlan0
10.8.0.1        10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.123.123.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Así que básicamente todo funciona, excepto el DNS que se está presionando ... ¡Oh! Derecha, y mi /etc/resolv.conf:

# Generated by NetworkManager
domain home
search home
nameserver 10.123.123.1

¿Dónde está el problema?

(Tengo una respuesta del usuario de Windows con el cliente openvpn, que por su parte DNS funciona bien, por lo que es un problema de mi parte.

Ok, ahora tengo otra respuesta (después de reiniciar el servicio openvpn en el lado del servidor): no funciona.

Debo decir que también funcionó ayer en mi máquina ... así que ¿he estropeado algo en el servidor? ¿Qué podría ser? )

Editar: De acuerdo, tengo otra respuesta de usuario de Windows (el mismo usuario que antes): está funcionando ahora. Entonces ... supongo que fue causado por el reinicio de openvpn y algunos retrasos. No he hecho nada desde entonces. Así que volvemos a mi máquina.

También rastreé que ese tun0mensaje extraño apareció también ayer, y ayer funcionó. ¿O tal vez agregué una entrada resolv.confpor mí mismo? No recuerdo .. (maldita sea)


He visto que esto sucede en sistemas con selinux habilitado y cuyo archivo resolv.conf tenía el contexto de seguridad de selinux incorrecto. La ejecución de restorecon para restaurar el contexto de seguridad en ese archivo resolvió el problema. PD: es resolv.conf, no resolve.conf
natxo asenjo

Ponga especial atención a /etc/NetworkManager/NetworkManager.conf: descomentar dns=dnsmasqy tener managed=true. Además, puede verse afectado por el error # 1294899 La conexión VPN guardada de importación se ha roto recientemente a pesar de una conexión VPN "establecida" informada. Verifique su configuración de VPN: coloque el nombre del protocolo ( :tcpo :udp) en el Gatewaycampo. Compruebe la configuración avanzada, especialmente Port numbery LZO compression. También verifique los registros. Termine con una prueba de fuga de DNS .
KrisWebDev

Respuestas:


23

Esto funciona para mí: http://www.softwarepassion.com/solving-dns-problems-with-openvpn-on-ubuntu-box/

El paso importante es agregar las siguientes dos líneas de configuración en el archivo de configuración openvpn de su cliente :

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

También asegúrese de que el resolvconfpaquete esté instalado en el cliente, porque ese update-resolv-confscript depende de él.

Funciona con el servicio de cliente openvpn o comando para iniciarlo manualmente.

Sin embargo, Ubuntu Network Manager no hace esto. Es un problema hasta ahora: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1211110


44
No olvide ejecutar openvpn con --script-security 2
kol

2
O también ponga script-security 2en su cliente el archivo de configuración openvpn.
KrisWebDev

No recomiendo usar OpenVPN directamente, sin pasar por Network-Manager, o puede enfrentar el error # 691723 OpenVPN Client ignora DNS que no tiene solución. En mi caso, Network Manager sobrescribió resolvconf después de que upse lanzó el script ... Un sucio # echo "nameserver 208.67.220.220" | /sbin/resolvconf -a "tun0.openvpn"DESPUÉS de ejecutar openvpn puede hacer el trabajo ... hasta que se sobrescriba nuevamente. Nuevamente, no use OpenVPN directamente.
KrisWebDev

upComando no encontrado !!
Pardeep Jain

@KrisWebDev: Eso es cierto, pero el uso de OpenVPN a través de NetworkManager permite a los usuarios deshabilitar (activar Off) la conexión que los administradores pueden no desear.
palswim

12

Funciona para mí después de deshabilitar dnsmasq de NetworkManager.

Editar /etc/NetworkManager/NetworkManager.conf

 #dns=dnsmasq

y reinicie NetworkManager

sudo restart network-manager

Ya tuve el cambio de Bruce Li en la configuración de mi cliente. Hacer este cambio también solucionó el problema [Ubuntu 15.10].
TheDauthi

1
¿Qué clase de brujería es esta? ¿Qué está haciendo dnsmasq?
GuySoft

Esto funcionó para mí en diferentes versiones de Ubuntu. Realmente no entiendo lo que hace dnsmasq, pero comentar esa línea de NetworkManager.conf resuelve mágicamente el problema para las conexiones VPN y las conexiones Wi-Fi.
Simón

Esto funcionó para mí ejecutando Linux Mint 18, aunque tuve que reiniciar mi máquina porque sudo restart network-manager falló con un error. La respuesta aceptada no funcionó para mí.
trebormf

en el error de lanzamiento del comando restart: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
restarte

2

Finalmente funciona (con NetworkManager estándar y el complemento OVPN)

nmcli -p connection modify MY_VPN_CONNECTION ipv4.never-default no
nmcli -p connection modify MY_VPN_CONNECTION ipv4.ignore-auto-dns no
nmcli -p connection modify MY_VPN_CONNECTION ipv4.dns-priority -42

En este caso, una vez que se establece la conexión VPN, todas las solicitudes DNS se dirigen a servidores DNS suministrados por VPN sin ninguna manipulación con scripts auxiliares dnsmasq, up / down / dispatch.


esto funciona, 10x
Roman M

1

Es posible empujar la configuración de DNS en OpenVPN. Como lo tiene en su configuración, se realiza en la configuración del servidor con la siguiente línea:

push "dhcp-option DNS 10.20.30.40"

Esto funciona desde el principio para mí usando la GUI de Windows, pero necesita un poco de empuje para los sistemas Linux. Para conectarme a mi red doméstica (usando Fedora 18 actualmente), utilicé un script de gronke en GitHub ( https://github.com/gronke/OpenVPN-linux-push ) para automatizar el proceso de actualización.

Para usar estos scripts, agregué lo siguiente a mi archivo de cliente OpenVPN:

up /home/gadgeteering/tools/vpn/up.sh
down /home/gadgeteering/tools/vpn/down.sh

up.sh:

#! /bin/bash
DEV=$1

if [ ! -d /tmp/openvpn ]; then
mkdir /tmp/openvpn
fi
CACHE_NAMESERVER="/tmp/openvpn/$DEV.nameserver"
echo -n "" > $CACHE_NAMESERVER

dns=dns
for opt in ${!foreign_option_*}
do
eval "dns=\${$opt#dhcp-option DNS }"
if [[ $dns =~ [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} ]]; then
if [ ! -f /etc/resolv.conf.default ]; then
cp /etc/resolv.conf /etc/resolv.conf.default
fi

cat /etc/resolv.conf | grep -v ^# | grep -v ^nameserver > /tmp/resolv.conf
echo "nameserver $dns" >> /tmp/resolv.conf
echo $dns >> $CACHE_NAMESERVER
cat /etc/resolv.conf | grep -v ^# | grep -v "nameserver $dns" | grep nameserver >> /tmp/resolv.conf
mv /tmp/resolv.conf /etc/resolv.conf

fi
done

down.sh:

#! /bin/bash
DEV=$1
CACHE_NAMESERVER="/tmp/openvpn/$DEV.nameserver"
echo $CACHE_NAMESERVER

if [ -f $CACHE_NAMESERVER ]; then
for ns in `cat $CACHE_NAMESERVER`; do
echo "Removing $ns from /etc/resolv.conf"
cat /etc/resolv.conf | grep -v "nameserver $ns" > /tmp/resolv.conf
mv /tmp/resolv.conf /etc/resolv.conf

done
fi

por qué es necesario dns=dns?
Wang

Esa sería una pregunta para Gronke, creo que también es un poco extraño. Desde que escribí mi comentario, pasé a usar una adaptación de este script que no usa la variable 'dns' en absoluto. No he observado ningún cambio en el comportamiento debido a la omisión.
Gadgeteering

1

Existe la posibilidad de hacer que NetworkManager funcione reemplazando manualmente /etc/resolv.conf. Tenga en cuenta que este es un truco y no puede considerarse como una solución válida para cada situación.

#!/bin/bash
case "$2" in
    vpn-up)
    tmp=$(mktemp)
    func=$(mktemp)
    echo 'ping -c 1 -w 1 -q $1 > /dev/null ;
          if [ 0 -eq $? ]; then echo $1; fi' > $func
    grep -v "^#" /etc/resolv.conf > $tmp
    grep -rl type=vpn /etc/NetworkManager/system-connections \
        | xargs -n 1 sed -rne 's|dns=||p' \
        | sed -re 's|;|\n|g' \
        | grep -v "^\s*$" \
        | xargs -n 1 bash $func \
        | sed -re "s|(.*)|nameserver \1|" \
        | cat - $tmp \
        > /etc/resolv.conf
    rm -f $tmp $func;;
    vpn-down) resolvconf -u;;
esac

Este script debe colocarse debajo /etc/NetworkManager/dispatcher.d; debe ser ejecutable y propiedad de root. Lee todas las configuraciones de NetworkManager vpn que puede encontrar y las reescribe /etc/resolv.confcon servidores de nombres accesibles que se encuentran allí. No escribe domainy searchlíneas; pero permite olvidarse del desagradable error de NetworkManager.

Yo uso Ubuntu 16.04, funciona.


0

OpenVPN actualmente no puede presionar la configuración de DNS. Tendrá que cambiar manualmente /etc/resolv.conf para que coincida con su servidor DNS (seguro). Acabo de ejecutar un servicio BIND9 en la misma máquina que mi servidor de acceso y apunto a través del túnel. Utilice su dirección IP local de esa máquina, p. Ej. 192.168.1.110

¡Buena suerte!

Jaspe


Con la respuesta de Bruce Li, el /etc/resolv.conf se modifica automáticamente
greuze

0

Tengo un cliente OpenSUSE que no usa resolvconf, systemd-networkdpero pude modificar el update-resolv-confscript común para trabajar con el nmclicomando de NetworkManager :

#!/usr/bin/env bash
#
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
#
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
# foreign_option_4='dhcp-option DOMAIN-SEARCH bnc.local'

case $script_type in

up)
    for optionname in ${!foreign_option_*} ; do
        option="${!optionname}"
        echo $option
        part1=$(echo "$option" | cut -d " " -f 1)
        if [ "$part1" == "dhcp-option" ] ; then
            part2=$(echo "$option" | cut -d " " -f 2)
            part3=$(echo "$option" | cut -d " " -f 3)
            if [ "$part2" == "DNS" ] ; then
                IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
            fi
            if [[ "$part2" == "DOMAIN" || "$part2" == "DOMAIN-SEARCH" ]] ; then
                IF_DNS_SEARCH="$IF_DNS_SEARCH $part3"
            fi
        fi
    done
    if [ -n "$IF_DNS_SEARCH" ]; then
        nmcli connection modify "${dev}" ipv4.dns-search "$IF_DNS_SEARCH"
    fi
    if [ -n "$IF_DNS_NAMESERVERS" ]; then
        nmcli connection modify "${dev}" ipv4.dns "$IF_DNS_NAMESERVERS"
    fi
    nmcli connection up "${dev}" # Force NM to reevaluate the properties
    ;;
esac

# Workaround / jm@epiclabs.io 
# force exit with no errors. Due to an apparent conflict with the Network Manager
# $RESOLVCONF sometimes exits with error code 6 even though it has performed the
# action correctly and OpenVPN shuts down.
exit 0

No tiene un downcontrolador porque NetworkManager elimina automáticamente los parámetros nameservery search(búsqueda de DNS) al finalizar la conexión.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.