Desde hace algún tiempo hemos visto en medios de comunicación noticias cada vez más preocupantes acerca de conexiones a internet que por un motivo u otro son espiadas. De hecho, para mi, la gota que colmó el vaso y que me ha animado a escribir esta guía ha sido esta, en la que se explica que determinadas operadoras de telefonía están espiando la navegación de sus propios usuarios para comprobar si están viendo alguna retransmisión pirata por internet.
Bueno... esos usuarios se supone que hacían cosas que no deberían hacer ¿No es así?
Pues no, Usuario Anónimo. No es así. Para ver si alguien está accediendo a una página «ilegal» o no, hace falta filtrar las páginas que ve cada usuario en sus dispositivos. Sólo así se puede bloquear a una persona para que no pueda acceder a una determinada web. Pero el problema es que no se han restringido a «capar» una página en concreto, sinó que se ha llegado a intentar detectar si alguien está usando determinadas páginas saltándose las vías habituales (lo explicaremos más adelante). Si han encontrado a gente que efectivamente está viendo contenido no autorizado, ha sido porque han vigilado a muchos usuarios y han visto el historial de navegación de TODOS ellos (incluídos los que no han hecho nada malo). Y qué quieres que te diga… a mi no me gusta que vean mi historial de navegación, aunque no consuma contenidos en streaming ilegales. Recuerda que se empieza buscando a gente que consume contenido pirata y se acaba buscando a gente de tal o cual inclinación política, sexual, religiosa o de cualquier otra índole. No, Usuario Anónimo. No todo vale.
Pues estamos bien. ¿Y cómo puedo evitar que mi operadora de intenet vea que yo frecuento páginas porn... estoooo.. de gatitos? Páginas de gatitos, ¿Eh?
Pues mira: normalmente ya estás encriptando el tráfico que recibes de las páginas web que visitas (tus páginas de… ejem… gatitos), porque ahora casi todas las páginas web que hay por internet usan https en lugar de http, lo que significa que recibes el tráfico de ellas encriptado (tanto el texto de la web como imágenes u otra clase de contenido). Sin embargo hay un tráfico que normalmente no está encriptado (y que algunas operadoras de telefonía están luchando para que no se encripte) y es el tráfico que traduce las direcciones que escribimos en la barra de direcciones de nuestro navegador en direcciones IP: el tráfico que cursamos hacia el servidor de DNS que tengamos configurado en nuestro equipo. Pero empecemos desde el principio. Veamos una simplificación de cómo funciona un servidor de DNS para comprender cuál es el problema y cómo podemos minimizarlo.
Funcionamiento de un servidor de DNS (A grosso modo)
Cuando queremos acceder a una página de internet, normalmente, en nuestro navegador ponemos en la barra de direcciones la dirección (URL de la página) a la que queremos acudir.
Exacto, justo debajo de las letras de Google.
A veces no sé cómo te soporto Usuario Anónimo. Eso no es la barra de direcciones, sinó la barra de búsqueda de la página web de Google, pero voy a pasártelo por alto porque es una confusión tremendamente común. Aprovecho para aconsejarte que si sabes la dirección de una web (URL), siempre debes ponerla en la barra de direcciones y nunca en la barra de búsqueda, porque si no lo haces así puedes tener algún disgusto en forma de fraude. De hecho no es el primero que busca una página en google y en los resultados de búsqueda sale de primero una página falsa que simula ser la que estás buscando. Doy fe que esto ha pasado no hace mucho con la página de Abanca, que es una entidad bancaria de Galicia (y que conste que la culpa de que esto pase no es de la entidad, sinó de que Google deje anunciarse en su buscador a una web que simula ser otra distinta).
En fin… supongamos que quieres acceder a una página web, como por ejemplo ésta misma (www.flopy.es). Así que corres raudo a poner esa dirección en la barra de direcciones del navegador y le das a «Enter». ¿Qué es lo que ocurre en ese preciso momento?
Esa me la sé. Que la página web se transmite desde el servidor en el que está alojada hacia tu ordenador y...
¡No, no no! Eso es lo último que pasa. Hay muchísimos ordenadores en el mundo conectados directamente a internet. ¿Cómo puede saber nuestro navegador de dónde hay que «recoger» los contenidos de esa web? Pues muy sencillo. Primero el navegador le pregunta a un servidor de DNS dónde está alojada esa web. Un servidor de DNS es algo así como una agenda dónde aparecen las correspondencias entre los nombres de dominio y la dirección IP en la que está alojado ese dominio.
Y qué es eso de que le pregunta a "un servidor de DNS". ¿Es que hay más de un servidor de DNS en internet?
Por supuesto. No es que haya más de uno, es que hay muchísimos. Cada operador de telefonía suele tener el suyo propio y todos ellos… para simplificar digamos que tienen un listado de correspondencias entre direcciones IP y nombres de dominio. (La realidad es bastante más compleja que esto que estoy explicando y pido perdón ya de entrada a los que sabéis perfectamente cómo funciona este tema, pero esta simplificación, aunque no se corresponda al dedillo con la realidad, ayudará a comprender el funcionamiento básico a quien no tenga ni idea de este tema).
Básicamente, lo que pasa es que nuestro ordenador le pregunta al servidor de DNS que tengamos configurado en qué dirección ip (En qué ordenador conectado a internet) se aloja la página que queremos ver. El servidor de DNS le responde que está en una dirección IP concreta, así que nuestro navegador, ahora que sabe la dirección en la que coger la web que nos interesa, solicita a la ip correcta que nos ofrezca los contenidos de esa página web. Pero aquí viene una cuestión clave que veremos dentro de un momento, y es que una máquina puede tener muchas páginas web alojadas y que cuelgan todas de la misma dirección IP. Por ejemplo, esta web que estás consultando ahora mismo la tengo alojada en un servidor que tengo en mi casa, pero en ese mismo servidor hay más páginas web por las que puedes navegar, y a cada una de ellas se accede por un dominio diferente (con una URL diferente). Por tanto, existen varios dominios muy diferentes que apuntan todos a mi servidor, y según vas escribiendo las diferentes URL en tu navegador, obtienes con cada una ellas una página web completamente diferente, aunque estén alojadas todas en el mismo equipo.
Este es, simplificando mucho (y vuelvo a pedir disculpas por no ser demasiado riguroso con la explicación), el funcionamiento normal de un servidor de DNS, pero este comportamiento normal lo están estropeando algunas operadoras de telefonía. Veamos qué está pasando.
Por qué los proveedores de internet no otorgan las DNS correctas a sus propios clientes.
Cuando un distribuidor de internet nos instala una línea de internet, lo más habitual es que por defecto estemos usando el servidor de DNS de nuestro proveedor de internet.
¿Y eso es necesariamente malo para nosotros?
La teoría nos dice que no. Nuestro proveedor de internet no debería inmiscuirse en si nos metemos en redes sociales, si leemos tal o cual diario digital o si somos adictos a páginas de… ejem… «gatitos». De hecho, si no confiamos en nuestra operadora de telefonía y cambiamos el servidor de DNS al que apunta nuestro equipo a algún otro servidor de DNS que esté operando en internet, le estaríamos dando las peticiones igualmente a ese otro ordenador, así que siempre habrá alguien que sepa por dónde navegamos (ya sea nuestra compañía de internet o el servicio de DNS al que hemos decidido apuntar), así que el problema no viene por ahí, sinó por los intereses de tu país (o resoluciones del sistema judicial) y los intereses particulares de las operadoras de telefonía.
Por un lado, es habitual que de vez en cuando el estado detecte determinadas páginas web que realizan algún tipo de actividad ilegal, así que cuando se detecta un caso de estos empieza a funcionar la maquinaria judicial y se decreta el bloqueo de la página, obligando a las compañías de telecomunicaciones que se impida el acceso a la misma.
Bueno... hasta aquí todo bien ¿no? Si alguien hace algo ilegal habrá que pararle los pies.
Por supuesto, y no voy a discutir que haya que impedir que la gente acceda a esa página. El problema es que hacer que sean las compañías de telecomunicaciones las que bloquean esas páginas no es la forma correcta de hacerlo. ¿Cómo crees tú que una operadora de telefonía impide el acceso a una página que le han mandado bloquear desde el juzgado?
Pues supongo que lo más sencillo será bloquear la IP del ordenador que sirve esa página y a correr ¿no?
Pues no. ¿Por qué no se puede hacer de esta forma? Pues te voy a poner un ejemplo: imagínate que quiero hacer una web de venta de… misiles termonucleares de largo alcance (ya de hacer algo ilegal, hacerlo a lo grande). Para alojarla me voy a un hosting cualquiera (vamos a suponer que contrato por intenet el alojamiento en uno de los hostings más grandes del mundo, que es GoDaddy). Tengo mi espacio web y empiezo a usarlo para a vender misiles balísticos a diestro y siniestro hasta que la policía ve que la gente, en lugar de comprar armamento nuclear en Aliexpress (que sería lo normal), empieza a comprarlo en mi web. La policía, ante la posibilidad de que alguien se compre en mi web un misil de esos y lo estampe en el casoplón de Pablo Iglesias, denuncia el caso y el juzgado dicta que esa web es ilegal y debe establecer algún tipo de actuación para parar este despropósito. Supón que decide hacer lo que dices tú: ve que la web se sirve desde una determinada dirección IP y se bloquea el acceso a esa dirección IP desde España. ¿Qué pasaría? Pues que muchísimas páginas alojadas en GoDaddy legalmente, dejarían de estar accesibles en España y puede que alguna gran empresa Española como Inditex tenga servicios en esos servidores bajo la misma IP que uso para mi negocio de misiles. El enfado que iba a tener el señor Amancio Ortega si sus webs dejan de ser accesibles podría ser descomunal, así que va a ser que al estado no le interesa salvar el casoplón de Pablo si es a costa de cabrear a Amancio.
Vale... pues que contacten con el alojamiento y con la orden judicial que se obligue al hosting a borrar la página en cuestión.
¡Ahí le has dado! Esa es la medida más correcta, pero… ¡¡¡Está alojada en otro país!!! Hay que iniciar trámites legales internacionales, interpol, etc… y seguro que cuando se le notifique a GoDaddy la obligación de cerrar la web yo ya tendré mis misiles a la venta en otro hosting de los miles que hay por el mundo (Será por hostings, vamos…). Lo suyo también sería que contactaran con el ICCAN, que es el organismo que se encarga de asignar los nombres de dominio a las direcciones IP, y que se diera de baja el dominio conflictivo desde ahí, pero supongo que de nuevo los trámites burocráticos son complicados (y por qué no decirlo… la opción que viene ahora le mola más a las operadoras).
Así que para hacer el bloqueo de forma sencilla y rápida, lo que se se empezó a hacer era pedirle a las operadoras que modificasen manualmente la correspondencia entre el dominio conflictivo y la dirección IP correspondiente. Si hacen esto, su servidor de DNS asocia el dominio de mi página de venta de misiles o bien a una dirección ip incorrecta (como la propia del router) o a alguna que a ellos les interesa para que cuando se intente ingresar en mi página, el usuario al final entre en otra página completamente distinta que informe al ususario de que esa dirección está baneada. La operadora de internet así no se mete en «fregaos» de banear ips que puedan contener páginas inocentes y el bloqueo es bastante efectivo, siempre que el usuario no use un proveedor de DNS distinto al de la operadora
Capto la idea. Entonces para poder comprarme una bomba de hidrógeno en tu página debo usar un servidor de DNS distinto al que me da mi proveedor de internet.
Así al menos era hasta ahora. Saltarse estos bloqueos era tan sencillo como cambiar el servidor de dns en nuestro equipo.
En todo caso ahora es momento de puntualizar algo importante: a veces no hace falta recurrir a bloqueos intencionados por parte de la operadora para tener una buena excusa para usar un servidor de DNS alternativo al que nos ofrece nuestro proveedor de internet, ya que algunas operadoras tienen muy descuidado el «mantenimiento» de estos servicios y hacen que resuelvan las DNS de forma incorrecta. Ante casos así la solución pasa directamente por usar DNS’s ajenas a la operadora. Os lo voy a mostrar con un caso real que me pasó a mi hace una década. Recuerdo que hace años tuve durante un tiempo a Jazztel como mi proveedor de internet y detecté un problema grave al resolver las DNS de una página en concreto que estaba gestionando (una web de una asociación deportiva). Todos los proveedores de internet asignaban correctamente la correspondencia entre la dirección IP y el dominio de la página menos Jazztel, pero si cambiabas manualmente las DNS en una línea de Jazztel por las de otro proveedor, el problema se resolvía. Llamé varias veces a Jazztel para informarles del problema y directamente me respondían que ellos no tenían ningún problema de ese tipo (sin ni siquiera dignarse a revisar nada, claro). Tardaron la friolera de un año en que esa web funcionara con sus propios DNS, así que durante ese año (y de ahí en lo sucesivo) usé los DNS de otro proveedor y problema resuelto (Si es que ellos mismos te obligan a hacer estas cosas).
Después de este inciso, volvamos al tema que nos interesa. Al ver que estos bloqueos se podían saltar muy fácilmente, las operadoras fueron un paso más allá (que no deberían haber dado) e implementaron la inspección de paquetes. Ahora, cada vez que solicitemos una página a través de nuestra conexión a internet, probablemente haya un filtro en la operadora que está mirando absolutamente todo el tráfico de datos de nuestro equipo en busca de palabras clave (Que van a ser los dominios baneados). Si encuentra que estamos realizando peticiones a otro DNS (aunque no sea el suyo), las intercepta y nos manda de nuevo a la ip que le interesa a la operadora en lugar de a la que queremos acceder (Tienes información bastante bien explicada de este tema en este enlace).
Bueno, vale... pero al fin y al cabo esto es para un buen fin. Lo siento por tu bollante negocio de armamento pesado, pero al menos así no habrá gente paseando ojivas nucleares por la calle y...
No te confundas Usuario Anónimo. Yo soy el primero que cree que determinadas páginas con contenidos ilegales hay que perseguirlas, pero no es lógico bloquear de esta forma por múltiples motivos.
En primer lugar, porque son las operadoras las principales interesadas en que desde su red no se vean determinados servicios, ya sean de la competencia o de particulares que hacen que sus ganacias se reduzcan (Como determinadas páginas que retransmiten eventos deportivos que sus clientes deberían pagar para ver a través de sus servicios). Permitir que las operadoras usen estos métodos puede hacer que se vean interesadas en bloquear cualquier web legal por sus propios intereses.
En segundo lugar, por el momento (recalco que por el momento) en España se puede disfrutar de determinadas libertades que no se dan en todos los países, pero nada nos asegura que el día de mañana cambie el gobierno y los gobernantes entrantes sean radicales de cualquier bando que quieran censurar páginas de ideologías contrarias a ellos (no es la primera vez que pasa, y si no me creéis revisad el caso de Turquía), así que los usuarios deberíamos tratar de evitar este tipo de bloqueos siempre.
Y en tercer lugar (y lo más importante): toda esta problemática nos ha hecho dar cuenta a mucha gente que de nada sirve que el contenido de las páginas web que visitamos esté cifrado, como está ahora en la mayoría de las webs, si no se cifran también las transferencias de datos que hacemos con los servidores de DNS.
Ahora sí que me he perdido. Si yo cojo una página por HTTPS la página está cifrada y nadie puede cotillear por dónde navego ¿No?
Sí y no. Cuando navegas por una página cifrada, la dirección de la página cambia de http a https y si el certificado de la página es válido podrás ver un candado al lado de su dirección, de esta forma.
Pero eso sólo nos garantiza que el contenido de la página se transmite cifrado. La petición que se hace al servidor de DNS que tengamos configurado para que nos ofrezca la página, en condiciones normales se hace sin cifrar, por lo que a nuestro operador de internet le resulta sencillo saber qué páginas visitamos (no verá el contenido de las páginas, pero sí podrá saber el listado de las que visitamos y bloquear las páginas que no les interesa que visitemos). Y por otro lado, si alguien se coloca con un aparato adecuado entre nosotros y el proveedor de internet, podrá consultar también ese tipo de tráfico y saber a qué páginas hemos accedido (No podrá ver el contenido de esas páginas, pero sí sabrá que he accedido a una web de venta de misiles).
Así que nos debería interesar mucho, por un lado dejar de usar los DNS que nos ofrece nuestra operadora de telefonía, y por otro cifrar el tráfico que cursamos hacia los servidores de DNS que nosotros elijamos.
El problema es que activar un cifrado de las DNS se hace de forma diferente en cada uno de los principales sistemas operativos. Pero hay una ventaja siempre que te hubiras animado a seguir el tutorial de pi-hole que publicamos en su momento: Si tienes implementado Pi-hole en tu casa, puedes encriptar todo el tráfico de DNS entre tu domicilio y tu provedor de DNS sin tener que tocar la configuración de ningún dispositivo.
Antes de ponernos al tema hace falta hacer una aclaración importante: esto va a permitir que no haya nadie entre la red del usuario y el servicio de DNS que pueda inspeccionar los paquetes de datos y ver por dónde navegas, pero no es la panacea y puede tener dos problemas que hay que conocer:
- La operadora, si quiere, puede bloquear el acceso a las IP’s de los servidores de DNS hacia los que queremos apuntar. Si hace eso, entonces tendremos un problema grave ya que no podremos realizar peticiones a esa IP (En Turquía, al ver que todo el mundo se saltaba el bloqueo a la torera usando los DNS de google, optaron por dejar éstos inaccesibles). Esto no ha pasado nunca en España y no debería pasar en ningún país serio, pero vete tú a saber qué pasa en el futuro.
- Una vez llega la petición a nuestro servidor de DNS, el propio servidor de DNS sí que va a saber qué página le hemos pedido. No lo sabrá nuestra operadora ni nadie que se quiera colocar en medio de la línea, pero sí nuestro proveedor de DNS (necesita saberlo para darnos la correspondencia correcta entre dominio e IP). Así que elegir el proveedor de DNS es una cuestión de confianza. Por ejemplo, yo evito usar siempre que puedo los de Google, que al fin y al cabo esa compañía ya tiene muchos datos de mi, como para darle aún encima todo mi historial de navegación.
En fin… que nos dispersamos. Vamos al lío.
Activar DNS sobre HTTPS (DoH) en Windows 10
Espera, espera... explica primero cómo usar DoH en Windows 7 u 8 ¿No?
Pues va a ser que no. De hecho, en el momento de escribir este artículo en windows 10 sólo se puede activar esta característica en equipos con windows 10 y además que se hayan añadido al programa de «Windows insider» (lo que significa que deberías tener un windows 10 «Beta») y no hay fecha prevista para ser añadida definitivamente al sistema (Aunque se baraja comienzos de 2021). Y es una pena, porque a pesar de que se puede habilitar DoH en algún navegador específico como Chrome (sin activar DoH en el propio sistema operativo), no sólo son los navegadores los que hacen peticiones a los servidores de DNS, sinó que otros muchos programas tabién se conectan a internet. Por tanto, si queréis activar DoH únicamente en vuestro Windows 10, la forma más conveniente de activarlo debería ser la que os voy a explicar dentro de un momento (en lugar de hacerlo en cada navegador por separado), así que espero que se pongan pronto las pilas los de Microsoft y lancen esta característica cuanto antes.
Pues ya les vale a los de Microsoft. Seguro que esto ya lo tienen arreglado los de Apple en su Mac OS o está disponible en cualquier distribución de GNU/Linux.
De nuevo te equivocas, usuario anónimo. Todos los sistemas operativos tienen esta característica aún muy verde y hay que hacer «ñapas» como la que vamos a ver ahora para Windows 10. Y de hecho te voy a decir una cosa: Personalmente y mientras no salga el parche definitivo que permita hacerlo de forma normal en el sistema os recomiendo no aplicar nada de esto. Para mi, la forma más correcta y efectiva de aplicarlo es hacerlo en un Pi-Hole (en este artículo os expliqué como montar uno). Para los que aún no sepáis qué es Pi-hole, se trata de un pequeño aparato que os quita la publicidad de todos los dispositivos que tenéis en vuestra casa. Os remito de nuevo a ese artículo dónde se explica de forma pormenorizada para qué sirve, cómo se monta y cómo se usa.
Si tenéis un Pi-hole montado en casa y os animáis a hacer lo que os explicaré en el último punto de este artículo (activar DoH en el pi-hole), podréis solventar este problema sin tocar la configuración de vuestro Windows, porque de esa forma activaríais DoH en absolutamente todos los equipos del hogar, sean o no compatibles con DoH. Os recomiendo encarecidamente montar algo en este sentido si queréis usar DoH. A fecha de hoy los sistemas operativos más habituales no están aún preparados del todo para usarlo (el próximo sistema de Apple, Big Sur, sí lo estará, pero aún no se ha publicado y como vais a ver dentro de un momento, activar DoH en Windows es hacer «ñapas» en una versión inestable del sistema). En linux supongo que las distribuciones irán añadiendo poco a poco opciones más sencillas para usarlo.
Al grano. al grano ¡Que te dispersas!
Tienes razón. Si tenéis Windows 10, os habéis agregado al programa «insider» y tenéis un número de compilación de Windows igual o superior al 19628 (y tenéis un trebol de cuatro hojas en el bolsillo derecho, un cuerno de unicornio y tres gotas de sangre de una virgen) podéis aplicar este punto.
¡Yo no puedo conseguir todo eso! ¿De dónde voy a sacar yo una virgen? ¡Que estamos en el siglo XXI!
Lo sé, lo sé… si es que de momento las cosas son así, qué le vamos a hacer. En fin… el número de compilación podéis verlo pulsando en el teclado la tecla con el logotipo de windows junto con la tecla «R» (Windows + R), escribiendo «winver» en el recuadro de ejecutar y pulsando «Aceptar».
En el diálogo que os sale, podréis ver información sobre vuestra versión de windows. Si os sale la 19628 o un número superior, podéis ejecutar este paso sin problemas.
Si cumplimos este requisito, podemos activar DoH para todas las aplicaciones del sistema Windows de la siguiente forma: desplegamos el menú inicio y sin pulsar en absolutamente ningún sitio tecleamos «regedit». Nos saldrá un resultado de búsqueda que se llama «Editor del registro». Lo pulsamos con el botón derecho y en el menú que se despliega pulsamos en «Ejecutar como administrador».
El sistema nos preguntará si queremos que la aplicación haga cambios en el dispositivo. Le diremos que sí.
Nos saldrá el editor de registro del sistema. En la barra superior tendremos que pegar la siguiente línea.
Equipo\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Para que el programa se vea tal que así.
En la parte de la derecha, donde están los otros valores, vamos a hacer click con el botón derecho y agregamos un nuevo valor de Dword.
Ese nuevo valor lo llamamos «EnableAutoDoh» y le damos el valor «2» hexadecimal.
Vale. Ya tenemos el sistema preparado para activar DNS sobre HTTPS. Ahora lo único que debemos hacer es apuntar las DNS de nuestro equipo a un servicio de DNS que soporte este protocolo. Se pueden usar varios, pero yo os recomendaría las DNS de cloudflare, que son éstas.
- 1.1.1.1 (IPv4)
- 1.0.0.1 (IPv4)
- 2606:4700:4700::1111 (IPv6)
- 2606:4700:4700::1001 (IPv6)
¿Y cómo las apunto a esas direcciones?
Pues sencillo. Abrimos cualquier ventana del navegador de archivos (una carpeta cualquiera de nuestro ordenador) y en el navegador de la izquierda buscamos el acceso que pone «Red». Lo pulsamos con el botón derecho y luego pulsamos «Propiedades».
Nos vamos a la conexión de red que tengamos activa (ya sea mediante WiFi o Ethernet).
Se nos abrirá una ventana nueva en la que deberemos pulsar el botón de «propiedades».
Seleccionamos el protocolo de internet versión 4 (TCP/IPv4)
Nos aseguramos de que esté marcada la opción de «Usar las siguientes direcciones de servidor de DNS» y ponemos un servidor de DNS que acepte DoH, como por ejemplo el de CloudFlare, que es el 1.1.1.1 y le damos a Aceptar.
Comentar también que hay por ahí alguna captura de pantalla circulando de las últimas compilaciones de windows, que indican que por lo que parece ya agregaron esta opción al panel de control nuevo del sistema (lo que facilitaría las cosas), pero en todo caso el método que os acabo de explicar os permitirá activar DoH en cualquier compilacion superior a la 19628.
Activar HTTP Over DNS en Pi-Hole
No tengo ninguna duda de que la que os voy a explicar ahora es la forma más correcta de activar DoH a fecha de hoy, porque extiende el sistema a todos los dispositivos de tu casa sin tener que configurar ninguno de ellos (Sólo habría que configurar el pi-hole). Además esto funcionaría para cualquier sistema operativo de los ordenadores que hay en tu hogar (da igual que sean Mac, Linux, Windows, Beos, Solaris, iOS, Android… os va a funcionar siempre).
Tal y cómo os dije en el punto anterior, hace un tiempo publicamos en este blog un pequeño tutorial para enseñaros cómo podéis montar Pi-Hole en una raspberry pi (o en un servidor linux). Pi-Hole es un software de servidor que nos permite quitar la molesta publicidad que tenemos en los dispositivos de nuestro hogar a la hora de navegar por internet. Usado conjuntamente con Pi-VPN vimos que también nos permite quitar la publicidad a cualquier dispositivo fuera de la red (en movilidad). Si a ese Pi-Hole le añadimos lo que vamos a explicar ahora, además de filtrar la publicidad nos permitirá saltarnos un montón de bloqueos de nuestra operadora de telefonía y hacer que nuestra navegación sea casi anónima por completo. Y ojo con el «Casi».
Síííí. Ya nos dijiste antes que el servidor de DNS al que apuntemos puede ver nuestra navegación.
Efectivamente, pero aquí va a haber un pequeño problema más, y es que el tráfico entre nuestro ordenador y el Pi-Hole, a nivel de DNS no estará encriptado. La encriptación con este método se hará de nuestra casa hacia afuera. Así que si alguien dentro de nuestra casa quiere cotillear por dónde navegamos, lo podría hacer con las herramientas y conocimientos suficientes. Aunque personalmente creo que no es algo que debiera preocuparnos en exceso.
Una vez dada esa advertencia, vamos a ver cómo activar DoH en nuestro Pi-Hole y para ello voy a tomar como referencia los pasos que se han seguido en esta web (son los que sigo yo cuando tengo que montar algo de esto), aunque nosotros vamos a intentar pararnos un poco más en la explicación para que nadie se me pierda.
El problema que vamos a tener para habilitar Doh en el Pi-Hole es que por desgracia Pi-Hole en estos momentos no es compatible de forma directa con DoH, por lo que haremos una pequeña trampa: Instalaremos un programa que permitirá al linux en el que esté instalado el Pi-Hole realizar peticiones mediante DoH al servidor de DNS que escojamos, y esa resolución de DNS se enviará, ya de la forma habitual y sin securizar, a nuestro servidor de Pi-Hole.
El programa será el cliente de Cloudflare para DoH (Que por cierto, tiene versiones para windows, Mac OS y Linux), que está disponible en esta página.
Pese a que la intuición seguramente nos lleve a instalar el .deb correspondiente (al menos si tenemos instalado pi-hole en una raspberry o un equipo con ubuntu o debian), vamos a usar el paquete binario para esta instalación.
Antes de nada y para evitar errores nos vamos a situar en la carpeta de nuestro usuario con el siguiente comando (podéis copiarlo y pegarlo en el terminal de vuestro linux).
cd ~/
Si nuestro Pi-Hole está funcionando sobre una raspberry con procesador de 32 bits, lo descargamos:
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
Si está funcionando sobre una raspberry con procesador de 64 bits, primero lo descargamos y luego le cambiamos el nombre al archivo (algún cenutrio olvidó de ponerle la extensión tgz).
wget https://github.com/cloudflare/cloudflared/releases/download/2020.8.2/cloudflared-linux-arm64 mv cloudflared-linux-arm64 cloudflared-linux-arm64.tgz
Si hemos instalado el pi-hole sobre un ordenador linux (no raspberry) con arquitectura X64, usaremos el siguiente comando para descargar la versión correcta para este caso.
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.tgz
Ahora que lo tenemos descargado, vamos a descomprimirlo con el siguiente comando si hemos descargado la versión para raspberry…
tar -xvzf cloudflared-stable-linux-arm.tgz
O con este otro si usamos Debian o Ubuntu.
tar -xvzf cloudflared-stable-linux-amd64.tgz
Vale… tenemos el programa ya descomprimido en la carpeta de nuestro usuario, así que vamos a moverlo a la carpeta correcta (que en este caso sería la ruta /usr/local/bin).
sudo cp ./cloudflared /usr/local/bin
Ahora le vamos a decir al sistema que lo que acabamos de copiar en esa carpeta es un ejecutable, y lo hacemos con este comando.
sudo chmod +x /usr/local/bin/cloudflared
Perfecto. Ya tenemos el cliente de Cloudflared instralado. Antes de continuar es una buena política comprobar que efectivamente responde, preguntándole por ejemplo qué versión hemos instalado. Lo hacemos con el siguiente comando.
cloudflared -v
Yo obtengo algo tal que así.
Pero dependiendo de en qué momento os animéis a hacer la instalación, os puede aparecer algo distinto. En todo caso lo importante es que este comando os diga qué versión del cliente de Cloudflare tenéis instalado.
Ahora vamos a hacer algo importante. Vamos a hacer que el cliente de cloudflare sea ejecutado por un usuario específico de nuestro equipo. No nos interesa que lo ejecute nuestro usuario habitual, así que vamos a crear un usuario llamado «cloudflared» con este comando.
sudo useradd -s /usr/sbin/nologin -r -M cloudflared
A estas alturas el cliente de Cloudflare está instalado, pero no está configurado. Podemos decirle que coja unas DNS u otras en función de nuestros gustos o necesidades. Para ello debemos crear el archivo de configuración con este comando.
sudo nano /etc/default/cloudflared
Y ahora debemos poner en el archivo de configuración qué servidores de DNS vamos a usar. Si, por ejemplo, queremos usar los servidores genéricos de cloudflare, pondremos en el archivo este contenido.
# Commandline args for cloudflared CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query --upstream https://1.0.0.1/dns-query
Pero podemos poner otros cualquiera. Por ejemplo, si nos interesa que no se pueda acceder desde los equipos de nuestra casa a páginas con virus o malware que puedan estropear nuestros equipos, podríamos usar los DNS de Cloudflare que te protegen contra estas páginas. En ese caso escribiríamos dentro del archivo este texto:
# Commandline args for cloudflared CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.2/dns-query --upstream https://1.0.0.2/dns-query
Si os fijáis, sólo han cambiado las direcciones IP en las que vamos a realizar las peticiones.
Yo, por ejemplo, tengo dos niños en casa y no me interesa que en mi red se pueda acceder a páginas con malware ni a páginas con contenido pornográfico, así que para evitarlo uso los dns 1.1.1.3 y 1.0.0.3, que van a bloquear cualquiera de estos dos tipos de peticiones, quedándome el archivo tal que así.
Una vez que hayamos puesto en el archivo los servidores DNS que nos interesan, guardamos cambios con la combinación de teclas «Control+O».
¿Os acordáis que habíamos definido un usuario específico en nuestro equipo para este programa? Pues vamos a hacer a ese usuario propietario de este archivo de configuración que acabamos de crear y del ejecutable del programa, y lo haremos escribiendo estos dos comandos en el terminal:
sudo chown cloudflared:cloudflared /etc/default/cloudflared sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared
Perfecto. Ya tenemos el programa preparado, pero tenemos que idear algo para que se ejecute nada más arrancar el sistema y que se quede en segundo plano, así que vamos a crear un servicio (también llamado en linux demonio o «Daemon») que haga esta función. Para ello creamos primero el archivo de configuración del demonio con este comando.
sudo nano /lib/systemd/system/cloudflared.service
Dentro de «nano» pegamos el siguiente contenido.
[Unit] Description=cloudflared DNS over HTTPS proxy After=syslog.target network-online.target [Service] Type=simple User=cloudflared EnvironmentFile=/etc/default/cloudflared ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS Restart=on-failure RestartSec=10 KillMode=process [Install] WantedBy=multi-user.target
De forma que nos quede tal que así.
Guardamos cambios con la combinación de teclas «Control + O» y activamos e iniciamos el recién creado servicio con estos dos comandos.
sudo systemctl enable cloudflared sudo systemctl start cloudflared
En condiciones normales todo debería haber ido bien, pero por si acaso vamos a realizar un par de comprobaciones: primero tecleamos este compando que nos diga si el servicio presenta algún problema.
sudo service cloudflared status
Si todo va bien, deberíamos ver algo como esto (Sin errores en rojo).
Y ahora vamos a comprobar si el programa que hemos instalado resuelve correctamente las DNS que le pidamos. Vamos a preguntarle a nuestro equipo (a la dirección 127.0.0.1, que es la del propio equipo) que nos diga la dirección ip en la que está alojada la página de cloudflare. Se lo pedimos tecleando lo siguiente:
dig @127.0.0.1 -p 5053 www.cloudflare.com
Ese comando nos debería sacar algo similar a esto.
Fijaos en los tres recuadros. El de arriba nos está diciendo que no hubo errores. El del medio nos dice a qué IP se está resolviendo el dominio cloudflare.com y el tercero nos dice que está preguntándoselo al propio equipo dónde está instalado el pi-hole.
Oye, en muchas partes de esta última explicación estás calcando el tutorial de Geekland que nos has dicho antes.
Más o menos. Como ya te he dicho antes, el orden en el que han puesto los comandos y la forma de proceder me ha gustado mucho, así que estoy siguendo su estructura para esta guía y no puedo hacer más que recomendaros visitar también su artículo.
En fin… en estos momentos nuestra máquina linux ya resuelve correctamente peticiones DNS a través de HTPS, pero tenemos que conseguir que las resuelva también nuestro Pi-Hole. ¿Cómo podemos hacerlo? ¿Cómo podemos conectar el cliente de Cloudflare al Pi-Hole que tenemos instalado? Pues sencillo: cuando instalamos pi-hole, tuvimos que escoger en su momento qué servidor de DNS iba a usar para resolver las DNS. En el tutorial que hemos seguido de Pi-Hole lo habíamos hecho en este punto.
Pues bien: ahora lo que debemos ordenar al Pi-Hole es que en lugar de usar los DNS de Cloudflare, que use los DNS… ¡del equipo en el que está instalado!
¿Lo qué? ¿Pero eso no hará que se pregunte las DNS a si mismo?
No, no. ¿Te acuerdas que unos pasos más atrás hicimos una prueba con un comando que empezaba por «dig @127.0.0.1 …»? Pues fíjate bien en la prueba, porque lo que has hecho ha sido preguntarle a la ip 127.0.0.1 en qué IP estaba una determinada página, y precisamente 127.0.0.1 es siempre la dirección de tu propio equipo. Esa resolución de nombres la respondió el cliente de Cloudflare. Así que imagino que te supones lo que vamos a hacer, que no es otra cosa que decirle al Pi-Hole que use como servidor de DNS externo la dirección 127.0.0.1.
Para ello debemos logarnos en nuestro Pi-Hole e ir a la opción «Settings» en la columna de la izquierda.
En la parte central de la página, debemos irnos al apartado «DNS», desmarcar cualquier DNS que hubiéramos escogido previamente (si habéis seguido nuestro tutorial de Pi-Hole, aseguraos de desmarcar el de Cloudflare) y en la parte derecha marcar la opción llamada «Custom 1 (IPv4)». En la casilla que hay inmediatamente debajo ponemos lo siguiente:
127.0.0.1#5053
Y una vez hecho esto, nos vamos a la parte inferior de la página y pulsamos el botón «Save».
Con esto quedará habilitado DoH en nuestro Pi-Hole, de forma que cualquier equipo que se conecte a nuestra red, ya sea por cable o por wifi, y que coja su dirección IP mediante DHCP, va a estar usando las DNS que le da nuestro pi-hole que previamente han sido conseguidas mediante DoH, por lo que indirectamente todas las aplicaciones de todos los equipos de nuestra red estarán usando DoH (Aunque su sistema operativo no sea capaz de usarlo).
Después de todo este rollo vamos a darle la palabra a nuestros lectores ¿Tu operadora te está impidiendo de alguna forma acceder a una página en concreto que necesitas visitar? ¿Has tenido algún problema para implementar DoH en tu Pi-Hole? Déjanos un comentario y cuéntanos tus impresiones.
Bueno, Vodafone no permite acceder a muchos sitios que se «ven bien» con el Kodi.
Intenté implementar esto con router Openwrt, que tengo dirigiendo una subred privada (problemas con compañeros de piso), pero me choqué con un muro de falta de conocimientos y tuve que volver atrás.
Tengo una raspberry 1B que vendría de maravilla, si fuera capaz de montar todo esto.
Cuidado con Vodafone. Este proveedor es muy dado a capar determinados puertos que deben mapearse para según qué cosas. Sin embargo creo que no deberías tener mayores problemas para montar algo del tipo pi-hole o lo que se comenta en este artículo (no hay que mapear puertos para hacer nada de esto).Lo único que te vendría bien (y que no es indispensable) es poner de servidor de dns en el router la ip de la raspberry, pero en caso de que no pudieras hacerlo (no todos los routers lo permiten) puedes poner manualmente la ip del pi-hole en los equipos que decidas.
Lo de Vodafone, es innegociable por el momento. La oferta de 2 móviles con tarifa plana de datos a velocidad 4G y llamadas ilimitadas, junto con 300 MB/s en casa por fibra simétrica y la tele (que no se usa) por 28 euros fijos al mes durante 2 años no hay quien la supere. Aun no sabemos cómo se ha conseguido eso. Cuando tenga tiempo, pruebo y te comento…
Sí, sí… Si ese es el problema. Te ponen precios baratos, pero a ver quién es el valiente que logra abrir el puerto 80 en una línea de esas. Por lo que tengo entendido en Vodafone no es posible (y otros muchos puertos también están capados, como el 25 o el 443). Míralo y nos comentas, que este tipo de cosas es interesante tenerlas claras. Aunque repito… eso no debería ser impedimento para montar un pi-hole en una línea de esas. A lo mejor un pivpn sí que puede dar guerra ya que requiere mapear al menos un puerto, aunque tengo entendido que los puertos «capados» por vodafone son unos muy concretos y creo que incluso podrías intentar poner un pivpn, pero vamos.. un pi-hole no debería presentarte problemas porque no requiere mapear puertos.
Interesante, pero el dig devuelve un SERVFAIL.
El servicio parece que está levantando y escuchando (acorde a netstat):
# netstat -puntave | grep 5053
tcp 0 0 127.0.0.1:5053 0.0.0.0:* LISTEN 998 209543 19235/cloudflared
udp 0 0 127.0.0.1:5053 0.0.0.0:* 998 209540 19235/cloudflared
En los logs (/var/log/cloudflared/cloudflared.log) no aperece nada.
Versión del programa:
# cloudflared -v
cloudflared version 2020.11.6 (built 2020-11-15-0224 UTC)
Mmmmm… puedo confundirme, pero puede que el problema sea la arquitectura del procesador de tu raspberry. Inicialmente puse en el tutorial una única descarga para el cliente de cloudflare en raspberry (la de 32 bits), pero os he añadido al tutorial la descarga de la versión de 64 bits. Puede que dependiendo del sistema operativo que uses y del modelo de raspberry tengas que instalar la versión de 64. Ya aproveché para corregir un problema en un enlace del artículo.
A ver si esto te resuelve.
No creo que sea la arquitectura, en principio es una Raspberry Pi 3 modelo B. En principio está todo a 32 bits:
# arch
armv7l
# file /usr/local/bin/cloudflared
/usr/local/bin/cloudflared: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, Go BuildID=EF96tcYZCL_8fBS_Qr1R/s5ZoglWhajJ0anWUw_fw/4q2M-v70_wew9me2CV1z/3_-MBkMzuhvG_yLDqBOn, BuildID[sha1]=0f36de71bc8f710599f939cf5e6fce5b4f9909a9, not stripped
También he probado a actualizar el cliente pero el problema persiste:
# /usr/local/bin/cloudflared -v
cloudflared version 2020.11.7 (built 2020-11-16-2023 UTC)
El problema es que sin logs poco se puede hacer
Muchas gracias, muy bien explicado. Ya configuré pi-hole con tu artículo y ahora he dado un pasito más con este. Funcionando
Muchísimas gracias por el desburre, Marcos.
En un par de horas tenemos ya pi-hole y DoH funcionando.
Ahora toca ver cómo funciona el nextcloud
Marcos, muchas gracias por tus tutoriales, son una gran ayuda para gente como yo que no somos muy expertos.
Tengo la siguiente duda:
Tengo instalado en mi Raspberry DNS sobre HTTPS (DoH) y PI-HOLE que me funcionan perfectamente. Al definir el DNS sobre HTTPS nos manda poner 127.0.0.1#5053 como servidor de DNS.
Ahora quiero instalar PiVPN y me manda poner de nuevo una dirección del servidor DNS. Mi duda es si debo conservar el DNS que ya tengo (127.0.0.1#5053) y de que si cambio dejen de funcionar las aplicaciones anteriores.
Espero que me ayudes con tu respuesta.
Ahora estoy intentando instalar PiVPN
Buenas noches, Marcos.
Segui tu tutorial, y el de geekland a la par. Todo bien, el servicio de cloudflare active, running. el comando dig me da la salida status:noerror. Pero en pihole, en cuanto le pongo el 127.0.0.1@5053 y le doy al boton save obtengo esto:
«Failed CORS: null vs 192.168.1.71, , 192.168.1.71, pi.hole, localhost».
Y si vuelvo, no me guarda dicho cambio.
Que es lo que hice mal? Algun consejo?
Y gracias por los tutoriales. Realmente son interesantes y de mucha ayuda.