Problemas con network-manager que afectan a DNScrypt. exDebian
  1. Inicio
  2. Foros
  3. Redes
  4. Proxy / Firewall / NAT / IPSec / Etc.
  5. Problemas con network-manager que afectan a DNScrypt.

Problemas con network-manager que afectan a DNScrypt.

10 envíos / 0 nuevos
Inicie sesión o regístrese para comentar
Último envío
#1 Mar, 13/09/2016 - 04:23
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

Problemas con network-manager que afectan a DNScrypt.

Estado: 
[SOLUCIONADO]

Hola amigos.

Soy usuario de una distribución basada en Debian Sid (Semplice), que tras una actualización ha ocurrido un problema con el paquete network-manager. Para poder activar DNScrypt necesito seleccionar, en las opciones de IPv4, "Solo direcciones automáticas", pero la opción "Guardar" parece desactivada, fijaos:

¿A qué se puede deber?.

Mar, 13/09/2016 - 07:52
Panko
Imagen de Panko
Conectado
moderador
se unió: 18/02/16

Desconociendo la versión tanto de network-manager como si usas gnome u otro escritorio (cambia la aplicación para configurar), y viendo lo que aparece en la captura (aunque no esté completa), Donde tienes metido la dirección 127.0.2.1 (dnscrypt-proxi), fíjate que indica "Servidores dns adicionales", cuando debe de indicar "servidores dns". Para direcciones automáticas ahi pondrías otros dns por si quieres usarlos si fallan los que configura automáticamente, mientras que si seleccionas automático (solo direcciones) esa casilla tiene que cambiar, ya que en este modo usa ningún dns que no le configures tu.

 

Por otro lado, ¿Has probado a configurarlo todo manual a ver si te deja guardarlo?

Estas cosas también pueden ser culpa de falta de permisos...

  No hay bar que por bien no venga....
Mar, 13/09/2016 - 11:01
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

Hola.

Efectivamente, estoy ahora desde otro ordenador que tiene la misma distribución y en el network-manager aparece únicamente Servidores DNS. Ese cambio se ha realizado tras una actualización que he hecho de la distribución. En atención a tu respuesta, voy a probar ejecutar el network-manager como root, por si fuera una cuestión de permisos; ahora bien, no entendería entonces por qué antes de la actualización sí podía hacerlo. Voy a ver.

En relación a modo manual, entiendo que te refieres a la terminal. Lo he intentado pero no he conseguido encontrar el archivo de configuración de red donde pueda cambiar esa opción. Seguiré buscando.

 

 

"O inventamos o erramos" (Simón Rodríguez)

Mar, 13/09/2016 - 12:11
rockyiii
Imagen de rockyiii
Desconectado/a
administrator
se unió: 11/01/16

Podrías fijarte en /etc/NetworkManager/system-connections/eth0

En este ejemplo ponenen los dns de google modificando el archivo anterior

...
[ipv4]
method=auto
dns=8.8.8.8;4.2.2.2;
ignore-auto-dns=true

saludos...

Mar, 13/09/2016 - 12:57 (Responder a #4)
Panko
Imagen de Panko
Conectado
moderador
se unió: 18/02/16

Liberto wrote:

Hola.

Efectivamente, estoy ahora desde otro ordenador que tiene la misma distribución y en el network-manager aparece únicamente Servidores DNS. Ese cambio se ha realizado tras una actualización que he hecho de la distribución. En atención a tu respuesta, voy a probar ejecutar el network-manager como root, por si fuera una cuestión de permisos; ahora bien, no entendería entonces por qué antes de la actualización sí podía hacerlo. Voy a ver.

En relación a modo manual, entiendo que te refieres a la terminal. Lo he intentado pero no he conseguido encontrar el archivo de configuración de red donde pueda cambiar esa opción. Seguiré buscando.

 

 

 

No me expliqué bien. Modo manual = ip fija, es decir, que metas tu todos los datos: ip, mascara de red, puerta de enlace, y dns. Una red se puede configurar de 3 formas:

  • automática: el sistema toma toda la configuración del router.
  • automática (solo direcciones): el sitema toma del router ip, mascara, y puerta de enlace. Las dns se las pones tu (es el modo que se suele usar con dnscrypt)
  • Manual: metes tu todos los datos.

Si has realizado alguna actualización y no has reiniciado el sistema (o, almenos, network-manager), es probable que no funcione bien, parece que no, pero network-manager tiene sus cosillas. Más de una vez me ha dejado de funcionar al actualizarse algún paquete suyo o del que dependa, cosa se se soluciona con systemctl reload-or-restart network-manager.service y, posteriormente, lo que use tu entorno, en mi caso systemctl restart  NetworkManager.service

 

Edito, ahora que releo bien, antes si podías y ahora no? mira en los logs que se actualizó entre que podías hacerlo y no puedes hacerlo. Posiblemente te haya desinstalado algo, quien sabe.

  No hay bar que por bien no venga....
Mar, 13/09/2016 - 18:19
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

En el archivo con la configuración de red:

/etc/NetworkManager/system-connections//etc/NetworkManager/system-connections/mi-red

He modificado los datos de IPv4, dejando esta configuración:

[ipv4]
dns=127.0.2.1;
dns-search=
ignore-auto-dns=true
method=auto

Pero cuando hago la comprobación en Network-Manager, todo sigue igual. Y al hacer el test de , se queda colgada la aplicación, nunca termina de informarme cuál es el servidor que resuelve las peticiones.

En relación a los logs de la actualización realizada, ¿a cuáles te refieres?, tengo varios archivos de logs y no sé cuál tendría que revisar.

"O inventamos o erramos" (Simón Rodríguez)

Mar, 13/09/2016 - 18:22
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

Y ahora veo el status de DNScrypt y no lo veo nada claro...

systemctl status dnscrypt-proxy.socket
● dnscrypt-proxy.socket - dnscrypt-proxy listening socket
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.socket; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:dnscrypt-proxy(8)
   Listen: 127.0.2.1:53 (Stream)
           127.0.2.1:53 (Datagram)

 

"O inventamos o erramos" (Simón Rodríguez)

Mar, 13/09/2016 - 19:16
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

Bueno, he conseguido resolver el problema de network-manager con un método realmente tonto, simplón y absurdo, pero eficaz: eliminar la red que usaba y volverme a conectar como si la usara por primera vez.

Pero ahora es DNScrypt quien me falla de nuevo. El estado es activo, pero esto sale cuando tecleo:

systemctl status dnscrypt-proxy.service
● dnscrypt-proxy.service - DNSCrypt proxy
   Loaded: loaded (/lib/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: enabled)
   Active: activating (start) since mié 2016-09-14 00:05:04 CEST; 47s ago
     Docs: man:dnscrypt-proxy(8)
 Main PID: 8114 (dnscrypt-proxy)
   CGroup: /system.slice/dnscrypt-proxy.service
           └─8114 /usr/sbin/dnscrypt-proxy --resolver-name=cloudns-can

sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] + DNS Security Extensions are supported
sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] + Namecoin domains can be resolved
sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] + Provider supposedly doesn't keep logs
sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [NOTICE] Starting dnscrypt-proxy 1.6.1
sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] Generating a new session key pair
sep 14 00:05:04 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] Done
sep 14 00:05:19 bigcipote-desktop dnscrypt-proxy[8114]: [ERROR] Unable to retrieve server certificates
sep 14 00:05:20 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] Refetching server certificates
sep 14 00:05:35 bigcipote-desktop dnscrypt-proxy[8114]: [ERROR] Unable to retrieve server certificates
sep 14 00:05:38 bigcipote-desktop dnscrypt-proxy[8114]: [INFO] Refetching server certificates

Entiendo que está teniendo problemas con los certificados del servidor, por lo que he cambiado de resolver name y ahora puedo navegar sin problemas. La cuestión es que cuando hago la prueba en DNSleaktest.com no me da resultado alguno, sino que la página se queda colgada. ¿Hay algún servicio alternativo parecido donde pueda comprobarlo?

"O inventamos o erramos" (Simón Rodríguez)

Mar, 13/09/2016 - 20:13
Liberto
Imagen de Liberto
Desconectado/a
se unió: 12/03/16

Bueno, y con esto cierro la incidencia.

 

Ya pude comprobar que DNScrypt funciona correctamente usando wireshark y el comando ip.addr == ip.del.resolver

Con esto comprobé que las conexiones entre mi compu y el servidor DNS estaban cifradas.

Cierro el parte y gracias a los dos por vuestra ayuda.

 

"O inventamos o erramos" (Simón Rodríguez)

Mié, 14/09/2016 - 05:55
Panko
Imagen de Panko
Conectado
moderador
se unió: 18/02/16

Una pequeña aclaración (y un consejillo, ya que estoy). Respecto a lo que ves en el estado del servicio de dnscrypt, piensa que cuando el sistema inicia éste, es más que probable que la conexión a la red no se haya efectuado todavía, por eso ves los errores al principio de que no puede conseguir el certificado. Puedes estar tranquilo que son errores normales (bueno, errores no, pero se puede considerar así).

Según mi experiencia, en algunos momento puede fallar el servidor dns que uses para dnscrypt. Lo que yo he hecho es añadir almenos dos al archivo de configuración, dejando uno de ellos comentado. De este modo, si observo algún problema, con descomentar uno y comentar otro, y recargando el servicio, vuelves a tener la resolución dns en marcha sin más problemas. Como ejemplo, la parte del archivo /etc/default/dnscrypt donde va el server:

# Remote DNS(Crypt) resolver.
# You can find a list of resolvers at
# /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv.
#DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.eu-nl
DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.eu-dk

con esto, no necestias recordar un server para cambiar de uno a otro, basta con descomentar el -nl, comentar -dk, y recargar el servicio con systemctl reload-or-restart dnscrypt-proxy.service

  No hay bar que por bien no venga....