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
