On Tue, Mar 27, 2001 at 07:57:40PM +0200, Francisco Callejo wrote:
El nsswitch.conf es correcto, con esa línea incluida; el host.conf
incluye también order hosts, bind, y en /etc/hosts están los nombres
de los dos ordenadores de la red. A pesar de todo, sigue dando
problemas a la hora de pedir un servicio de un ordenador al otro.
Resumo la situación:
- Ordenador A: conectado a la línea RDSI, y con ipchains activado en
un kernel 2.4.1. (con el módulo ipchains.o, no con iptables).
- Ordenador B: conectado por tarjeta de red al ordenador A.
- El ordenador A puede hacer peticiones al B tanto por nombre como por
dirección IP (192.168.1.1).
- El ordenador B puede hacer peticiones al A que no sean tcp (ping,
traceroute) por nombre y por ip (192.168.1.2).
- El ordenador B tiene en su tabla de rutas al A como gateway.
- Si A está conectado a Internet, B puede hacer peticiones a A de
servicios tcp por su nombre.
- Si A _no_ está conectado a Internet, B sólo puede hacer peticiones
tcp a A por ip. (También por nombre, pero tarda muchísimo en
responder).
Esta situación me ocurre desde hace unos días (anteriormente todo iba
bien) y supongo que tendrá relación con algún .deb que haya instalado
últimamente, pero no sé cuál. Los ficheros de configuración no los he
tocado desde hace tiempo.
Si a alguien se le ocurre algo, que me lo diga.
Desde ya, para evitar falsas esperanzas, NO tengo la solución, pero...
Te cuento.
Mi situación es practicamente idéntica a la tuya (conexión RDSI, ordenador
con linux haciendo de router y red interna 10/100, en mi caso con 6 máquinas)
y exactamente el mismo problema con la resolución de nombres.
Primera consideración: el problema no está relacionado con /etc/hosts, ni con
/etc/nsswitch.conf, ni con la versión del núcleo. Tu ejecutas kernels 2.4.x,
yo tengo todas las máquinas con kerlnels 2.2.14 y 2.2.18 (bueno, menos una que
tiene un minix, pero para el caso no cuenta)
Yo detecté el problema al instalar la ver. 0.17.x de los paquetes telnet y
telnetd en la máquina en la que trabajo habitualmente. En esta primera
actualización, si el router no estaba operativo, telnet no conectaba ni
proporcionando un nombre canónico ni proporcionando una dirección ip y telnetd
no admitía una conexión al no poder realizar una resolución inversa de la
dirección ip del cliente. Si el router estaba operativo, el cliente solicitaba
la resolución del nombre a los nameservers de mi ISP y al obtener contestación
negativa de estos por fin se dignaba mirar en /etc/nsswitch.conf. El servidor
(telnetd) realizaba su resolución inversa por el mismo procedimiento.
En una versión de telnet que bajé unos días después este había modificado su
comportamiento y permitía la conexión sin intentar resolución de nombres
cuando le proporcionaba directamente una dirección ip. El comportamiento del
telnetd seguía siendo el mismo. Cansado de esto, decidí downgradear a la ver.
0.16.x de estos paquetes y todo volvió a funcionar normalmente.
Investigando algo el tema en los archivos de listas de correo de debian, en
el bug tracking y en las news, lo único que pude obtener es un aviso de un
problema de seguridad referido al paquete libc6 que literalmente dice If a
stuid program does not drop privileges before calling resolver functions,
arbitrary file on the system can be read by setting the RESOLV_HOST_CONF
environment variables, que es contestato por el mantenedor del paquete
informando que soluciona el problema (no se si provisionalmente) haciendo
que las funciones de la librería para resolución de nombres try absolute
lookups first. No se si esto tiene que ver con el problema que tenemos, pero
si fuera así debería afectar a todos los programas que utilicen las funciones
de resolución de la libc6 2.2 posteriores a este arreglo (01-2001).
Saludos.
rlp
