El 6 de noviembre de 2019 1:48:38 CET, "ziprasidone146939...@gmail.com"
<ziprasidone146939...@gmail.com> escribió:
>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
ziprasidone146939277, buenos días,
Si fuese problema de Enrutamiento IP, al hacer, por ejemplo, un Ping, a 1.2.3.4
(host.pepe.org), y sin que haya firewalls de por medio, no respondiera, que no
es el caso. Pero si responde lo anterior, y al hacer Ping a host.pepe.org
(1.2.3.4) dice que no existe, es problema de resolución.
Tanto el Cliente VPN, como si se conectan a la LAN, deben poder RESOLVER los
FQDN de cualquier red, y si por DHCP, tanto a los Clientes de la VPN, como a
los de la LAN, se les asignan los DNS, siempre busca en el Primario, a no ser
que esté "muerto", que, en ese caso, pasaría a buscar en el siguiente, y si le
asignas como Primario el de la LAN, nunca resolverá los FQDN del resto de
redes, salvo que los des de alta en éste o le metas las líneas que he puesto.
Si crees que eso se puede resolver desde la parte del Cliente, sin que la
solución sea meter todos los FQDN en el fichero /etc/hosts o instalar un DNS
local en cada Cliente, comenta el cómo se podría hacer.
Saludos y gracias,
Ramsés
