Tengo un problema que es "NetworkManager no se actualiza /etc/resolv.conf
despué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, [email protected]
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, [email protected]
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, [email protected]
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, [email protected]
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 tun0
mensaje extraño apareció también ayer, y ayer funcionó. ¿O tal vez agregué una entrada resolv.conf
por mí mismo? No recuerdo .. (maldita sea)
/etc/NetworkManager/NetworkManager.conf
: descomentardns=dnsmasq
y tenermanaged=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 (:tcp
o:udp
) en elGateway
campo. Compruebe la configuración avanzada, especialmentePort number
yLZO compression
. También verifique los registros. Termine con una prueba de fuga de DNS .Respuestas:
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 :
También asegúrese de que el
resolvconf
paquete esté instalado en el cliente, porque eseupdate-resolv-conf
script 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
fuente
script-security 2
en su cliente el archivo de configuración openvpn.up
se 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.up
Comando no encontrado !!Off
) la conexión que los administradores pueden no desear.Funciona para mí después de deshabilitar dnsmasq de NetworkManager.
Editar
/etc/NetworkManager/NetworkManager.conf
y reinicie NetworkManager
fuente
restart: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
Finalmente funciona (con NetworkManager estándar y el complemento OVPN)
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.
fuente
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.sh:
down.sh:
fuente
dns=dns
?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.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.conf
con servidores de nombres accesibles que se encuentran allí. No escribedomain
ysearch
líneas; pero permite olvidarse del desagradable error de NetworkManager.Yo uso Ubuntu 16.04, funciona.
fuente
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
fuente
Tengo un cliente OpenSUSE que no usa
resolvconf
,systemd-networkd
pero pude modificar elupdate-resolv-conf
script común para trabajar con elnmcli
comando de NetworkManager :No tiene un
down
controlador porque NetworkManager elimina automáticamente los parámetrosnameserver
ysearch
(búsqueda de DNS) al finalizar la conexión.fuente