El 2009-04-30 a las 18:36 +0200, carlopmart escribió:
Camaleón wrote:
Sí, está a cero :-? *** HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ IPEnableRouter REG_DWORD 0x00000000 (0) ***
Pues el tema está entre el windows y al switch que conecta, no puede ser nada más. ¿Tienes otro linux en la red 192.x.x.x? ¿Puedes sniffar a ver si ve ese tráfico?
Sólo capturo datos desde la suse que registra esos eventos. Bueno, la película es como sigue. Una consola la dejo con: *** linux:/etc/samba # tail -f /var/log/firewall *** Y otra con: *** linux:~ # tcpdump src 10.5.110.1 or dst 172.16.0.30 or dst 192.168.0.13 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes *** Cuando el cortafuegos registra el evento: *** May 1 12:54:12 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx SRC=10.5.110.1 DST=192.168.0.5 LEN=56 TOS=0x00 PREC=0x00 TTL=254 ID=0 PROTO=ICMP TYPE=3 CODE=13 [SRC=192.168.0.5 DST=172.16.0.30 LEN=221 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=137 DPT=137 LEN=201 ] May 1 12:54:43 linux syslog-ng[2288]: last message repeated 2 times *** El tcpdump captura esto otro: *** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.375157 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 12:54:13.819434 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:13.863304 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 12:54:15.319569 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:15.364446 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 *** ----- Notas ----- - 192.168.0.5 es la eth0 de suse - 192.168.0.13 es la eth0 del windows xp64 - 172.16.0.30 es la eth1 del windows xp64 - El samba en suse lo tengo para que los clientes puedan usar la impresora de faxes a través de CUPS. ------- Pruebas ------- - He probado a definir la misma métrica para ambos adaptadores en el xp (métrica de 10). Los adaptadores con la misma métrica basan su prioridad en el orden de las interfaces. La primera es eth0 y la segunda es eth1. Haciendo esto y reiniciando el windows seguía registrando estos mensajes en el cortafuegos. - He probado a detener el servicio nmb (rcnmb stop) y también dejó de registrar estos eventos en el cortafuegos. Es decir, el mismo efecto que desactivando la interfaz desde windows. - También he probado a definir los siguientes valores en el archivo de configuración de samba (/etc/samba/smb.conf): bind interfaces only = yes interfaces = 192.168.0.5 Y reiniciar ambos servicios (nmb y smb) pero sigue registrando los eventos - Otra cosa que también he probado es a añadir en el cortafuegos la siguiente entrada: FW_SERVICES_DROP_INT="0/0,udp,137" Y por si estuviera tomando la interfaz como ext (creo que lo hace así porque no lo he definido expresamente), también probé: FW_SERVICES_DROP_EXT="0/0,udp,137" Y reiniciando el cortafuegos, pero seguía registrando los eventos. --------- Hipótesis --------- - El tcpdump parece indicar que no es el windows quien intenta comunicar con la suse, sino al revés. SuSE manda un paquete tanto a 192.168.0.13 como al otro adaptador 172.16.0.30: *** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST *** Y al hacerlo le viene la respuesta lógica de que "no llega": *** 12:54:12.375157 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 *** - Hay otros equipos en la red que tienen dos adaptadores de red pero curiosamente este comportamiento sólo se da con uno en concreto (windows xp64). Lo cual me hace pensar que podría ser alguna característica nueva que se ha incorporado en el xp64 (que comparte algunas de las opciones del w2003). Tendré que revisarlo. - Voy a seguir buscando información para intentar al menos evitar que se llene el registro del cortafuegos con esos datos. Si se os ocurre alguna otra cosa para probar, pues se agradece :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org