On Tue, 2019-11-05 at 19:55 +0100, Ramses wrote:
> El 5 de noviembre de 2019 13:00:09 CET, Debian <
> javier.debian.bb...@gmail.com
> > escribió:
> > El 4/11/19 a las 14:33, Ramses escribió:
> > > Hola a tod@s,
> > >
> > > Yo tenía entendido que en Linux, tener varios DNS en
> > > /etc/resolv.conf
> >
> > funcionaba de la siguiente forma. Por ejemplo, en el
> > /etc/resolv.conf
> > lo siguiente:
> > > nameserver 1.1.1.1
> > > nameserver 2.2.2.2
> > > nameserver 3.3.3.3
> > >
> > > Pensé que si buscamos una máquina "maquina.pruebas.org":
> > >
> > > - La buscaba en el /etc/hosts
Si.
> > > - Si no la encontraba, la buscaba en el 1.1.1.1
Si. Digamos por default es asi, el orden se puede modificar, pero de
fabrica funciona asi.
> > > - Si no la encontraba, la buscaba en el 2.2.2.2
No.
> > > - Si no la encontraba, la buscaba en el 3.3.3.3
> > > - Y si tampo la encontraba, daba el error de que no existe esa
> >
> > máquina.
> > > Al contrario que hace Windows, que mientras que esté vivo el
> > > primero
> >
> > de los DNS, no busca en el siguiente si no existe la máquina en
> > este
> > primer Servidor DNS.
> > > ¿Estoy equivocado con esta creencia mía?
Mas o menos. Entiendo que la condicion para que salte o se use 2.2.2.2
(siguiendo el ejemplo) es que 1.1.1.1 de timeout o unreacheable.
Si 1.1.1.1 contesta NXDOMAIN, 2.2.2.2 no se usa. Y se entiende que
1.1.1.1 esta funcionando porque contestó que ese dominio (al menos para
1.1.1.1) no existe.
> > >
> > >
> > > Saludos y gracias,
> > >
> > > Ramsés
> > >
> >
> >
> > Sí, pero más o menos.
> > El tema es largo.
Coincido.
> >
> > Tu problema no es resolv.conf, tu problema es enrutamiento.
Si. Me animaría a decir que más precisamente de métricas.
> >
> > man route
> >
> > Primero, /etc/resolv.conf funciona de dos maneras y tiene sus
> > limitaciones.
> > Por compilación del kernel, sólo puede manejar hasta 3 DNS y 2
> > dominios
> >
> > de búsqueda; si querés agregar más, debés recompilar el núcleo a
> > mano;
> > no lo aconsejo. Además, en general, con 3 alcanza, pues rara vez
> > tienes
Exacto, en resolv.conf, los DNS declarados a partir del tercero no son
tenidos en cuenta.
> >
> > más de 3 interfaces de red, conectadas a 3 redes distintas.
> >
> > Por otra parte, resolv.conf funciona en forma estática o dinámica.
> > La estática, es la que creo estás usando vos, metiendo dedos en el
> > archivo.
> > La dinámica, es manejada por el paquete resolvconf.
> > # apt install resolvconf.
> >
> > Esta última se configura con cada reinicio de su respectivo
> > demonio.
> > Fijate si no lo tenés corriendo con
> > # systemctl status resolvconf.
> >
> > Este demonio se controla a través de sus archivos de configuración
> > /etc/resolvconf, y/o a través de instrucciones dinámicas que se
> > cuelgan
> >
> > en el archivo /etc/network/interfaces.
Pausa. El paquete resolvconf no viene instalado por defecto en debian
10. De modo que esto es relativo. Si el OP tiene o usa ese paquete,
esto puede servir si no, no.
> >
> > Un tema MUY importante: si manejás varias redes, asegurate que las
> > mismas estén es segmentos distintos, que me parece que es lo que te
> > está
> > pasando.
> >
> > Por ejemplo, te copio lo que yo tengo colgado para manejar dos
> > redes en
> >
> > segmentos distintos, y que además, para evitar colisiones, está
> > configurado el ruteo de redes sobre cada una de las interfaces.
> > Es fundamental que el DNS de tu VPN esté bien configurado, y
> > recuerda
> > que en una VPN, los servidores deben estar con direcciones
> > estáticas y
> > los usuarios con dinámicas.
> >
> > Lo que está escrito después de => no hay que agregarlo al archivo,
> > lo
> > escribo ahora para que sepas qué hace.
> >
> > /etc/network/interfaces
> > ======================================================
> > # This file describes the network interfaces available on your
> > system
> > # and how to activate them. For more information, see
> > interfaces(5).
> >
> > source /etc/network/interfaces.d/*
> >
> > # The loopback network interface
> > auto lo
> > iface lo inet loopback
> >
> >
> > # EMPRESA => esta es la VPN
> > auto enp2s0
> > allow-hotplug enp2s0
> > iface enp2s0 inet dhcp
> > hostname userw39 => el nombre de host para la red de mi empresa
> > dns-nameserver 10.115.1.201 => DNS de la VPN de la empresa
> > dns-search mi.empresa => dominio de la empresa
> >
> > # Internet
> > auto enp3s0
> > allow-hotplug enp3s0
> > iface enp3s0 inet dhcp
> > hostname jap => el nombre de host con que salgo a internet
> > dns-nameserver 192.168.13.1 => DNS del enrutador que sale a
> > internet
> > dns-nameserver 8.8.8.8 => DNS de Google
> >
> > # Enrutamiento => Fuerza a cada interfaz a ceñirse a un segmento
> > específico. Lo que está en el segmento de la empresa, va por la
> > interfaz
> > enp2s0, el resto sale por internet a la enp3s0.
> >
> > post-up ip route change default via 192.168.13.1 dev enp3s0
> > post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.112.1.254
> > dev
> > enp2s0
> >
> > # Enrutamiento => estos son dos servidores que uso mucho, y al
> > ponerlos
> > en forma estricta, no busca en los DNS pues tiene la ruta
> > explícita.
> >
> > post-up route add -host 10.1.0.231 gw 10.112.1.254 dev enp2s0
> > post-up route add -host 10.1.12.201 gw 10.112.1.254 dev enp2s0
> >
> > ========================
> >
> > Espero te sirva.
> >
> > JAP
>
> JAP, gracias por contestar.
>
> No, no es un problema de enrutamiento, es un problema de resolución,
> ya que son redes distintas con DNS's distintos. De hecho, si tiro un
> Ping a cualquier IP de cualquier máquina de las redes a las que
> quiero llegar, responden sin problemas, el tema está en que si
> intento acceder por el nombre FQDN, siempre me lo intenta resolver el
> Primer Servidor DNS establecido en el "/etc/resolv.conf", que es el
> de mi LAN y, evidentemente, las máquinas de la otra red o redes, no
> las tengo definidas en mi Servidor DNS, por lo que la respuesta del
> DNS es que no existen esas máquinas.
>
Tu problema no es de llegar o no (esta bien que con ping
<ip.server.mi.vpn> funcione); lo que quieres (o el problema) es
resolver un FQDN con un DNS que no sabe nada de ese dominio (el dominio
de tu VPN) porque se esta usando el DNS incorrecto.
JAP ha echado bastante luz al asunto.
Y si, hay un problema de "enrutamiento": tienes que decir (de alguna
forma) que la red de tu VPN tiene un mayor prioridad sobre el DNS de
esa VPN (o algo parecido) para que el destino de tu VPN (mas
exactamente el DNS que resuelve los nombre de tu VPN, para cuando
intentes resolver una direccion de ese dominio) no use el DNS 1.1.1.1
sino el de tu VPN (prioridad/metric).
Y ademas otro problema: el DNS de tu VPN tendra que poder resolver
google.com para sus clientes, de otro modo, cuando este conectado a la
VPN no vas poder resolver dominios publicos.
Tambien utilizar la opt. search <midominio.xyz>; como en alguno de los
ejemplos que postuló JAP desde network/interfaces.
Y es un problema de enrutamineto porque allí se manejan las metricas o
prioridades de los destinos e interfaces.
> El dominio, o dominios, de las otras redes son internos, a las que
> llego a través de VPN's Site-to-Site, y como he comentado, lo que
> tengo como Primer Servidor DNS, tanto en el DHCP Server como en los
> Clientes VPN, es un Servidor DNS BIND9, el de mi LAN, que administro
> yo, por lo que he optado por tocar la configuración de éste metiendo
> en el "named.conf.local" lo siguiente:
>
> zone "paco.org" {
> type forward;
> forwarders { 1.1.1.1; };
> };
>
> zone "pepe.org" {
> type forward;
> forwarders { 2.2.2.2; };
> };
>
> Por lo tanto, cuando busque un FQDN del dominio "paco.org" manda la
> petición de resolución a un DNS y cuando es del dominio "pepe.org" lo
> manda al otro.
>
> Todo funcionando.
>
> Lo estaba intentando solucionar desde la parte del Cliente, pero esta
> parece ser la solución más "limpia".
Y es que el problema esta en el cliente.
>
> Con 3 líneas, solucionado...
>
> Espero que les sirva.
>
> No sé si a alguien se le ocurre una mejor opción.
>
Si asi te funciona esta bien. Pero creo que tu problema es mas o menos
lo que dijo JAP y algo de que te he comentado. Puede que algunas cosas
sean incorrectas (para eso esta la lista).
>
> Saludos y gracias,
>
> Ramsés
>
>
Saludos
