Re: Red VS. Servidor
On 15 de març de 2014 0:20:33 CET, "Germán Cervantes" <germanicg@yahoo.com.mx> wrote:
>Hola.
>
>Es una IP fija pública (homologada), nada de NAT ni firewall de red;
>sólo Iptables; servicios solamente http (80) y smtp (25)
>
>Si, he revisado las bitácoras, sobre todo en busca de un mensaje de IP
>duplicada; pero no hay ningún mensaje de error, ni de la NIC, ni de
>ninguna otra cuestión de hardware o software, que me de indicios de que
>algo ande mal o que el S.O. detecte algo.
>
>A lo que me refiero con el área de redes dice que todo bien; es que me
>comentan que no ven nada extraño; salvo que los paquetes llegan al
>servidor; es decir, ellos piensan que el problema es de mi servidor y
>no me dan más explicaciones y pues, ustedes saben, es difícil pedirles
>que hagan más pruebas desde el exterior, no acceden tan fácil, ya que
>no lo ven necesario.
>
>Pero mi servidor está bien; ningún proceso extraño; comunicación en la
>LAN bien; acepta el ping y veo las páginas sin problemas, bitácoras
>normales; salvo que no recibo conexiones externas http (access.log),
>salvo algunas de la LAN.
>
>Al momento del problema en mi servidor, externamente (WAN) no recibe el
>ping, ni mucho menos establece conexión a puerto 80 o 25 que son los
>que tengo abiertos. Normalmente tengo cerrado el ping externamente,
>pero lo abrí para hacer pruebas. De hecho configuré un servicio
>gratuito externo para que esté monitoreando mi servicio HTTP, se los
>paso al costo.
>
>http://uptimerobot.com/
>
>
>Muchas gracias por sus comentarios; seguiré probando con trazas de
>ruteo para obtener pruebas, y revisaré más a fondo los procesos;
>también trataré de ver algunos comandos de la NIC para revisarla mejor
>o probar con otra NIC; aunque como comentaban no recibo mensajes de
>error en las bitácoras (syslog, messages, kern.log, etc).
>
>
>netstat -i
>Kernel Interface table
>Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR
>TX-DRP TX-OVR Flg
>eth0 1500 0 43240585 0 0 0 23480184 0 0
> 0 BMRU
>lo 16436 0 459670 0 0 0 459670 0 0
> 0 LRU
>
>
>Saludos.
>
>------------------------------
>El Viernes, 14 de marzo, 2014 13:58:27, Erick Ocrospoma
><zipper1790@gmail.com> escribió:
>
>Hola,
>
>Haz revisado los logs del sistema? los logs del kernel (dmesg) ?
>Solíamos (ó solemos) tener casi el mismo problema, y bueno reiniciando
>el servicio de red al parecer se arreglaba todo pero siempre que esto
>sucedía en el /var/log/syslog encontraba un par de errores respecto a
>la tarjeta de red, la primera solución fue mantener actualizado el
>driver hasta que se decidió cambiar de NIC. No sé si sea tu caso pero
>suena a eso, revisa bien :-)
>
>
>
>2014-03-14 13:22 GMT-05:00 Fredy Guio <fredy.guio@gmail.com>:
>>
>> ---------- Forwarded message ----------
>> De: "Germán Cervantes" <germanicg@yahoo.com.mx> Date de fermeture:
>> 2014-03-14 14:01 réserve de droits: Red VS. Servidor
>> Pour: "debian-user-spanish@lists.debian.org"
>> <debian-user-spanish@lists.debian.org>
>> Cc :
>>
>>> Hola.
>>>
>>> Tengo el típico problema del huevo y la gallina, pero entre la red y
>el
>>> servidor; sucede que de repente mi servidor no puede recibir
>peticiones de
>>> HTTP externamente, aunque internamente si veo el servidor y no me
>presenta
>>> ninguna saturación pensando en un posible DOS; en el access .log veo
>que
>>> sólo se registran peticiones de una sóla IP de la LAN y ninguna
>externa
>>> (WAN) por lo que pienso que es un problema de ruteo, tal cual.
>>>
>>> Pero me dicen en redes que todo está bien.
>>>
>>
>> Clasica pelea.
>>
>>> La forma en que lo soluciono es dando de baja la NIC y volviendola a
>>> activar; pensé en suplantación de mi IP, pero me dicen que ya lo
>hubieran
>>> detectado y en mis bitácoras no tengo registros de IP duplicada.
>>
>> Esto si es como raro. Ya que si hubiece alguna regla de red
>bloqueando tu
>> trafico http desde afuera, el problema no se solucionaria bajando y
>subiendo
>> la NIC ya que las reglas de la red no varian si tu apagas o enciendes
>tu
>> tarjeta. Punto a favor para la gente de redes.
>>
>>>
>>> ¿Qué pruebas me sugieren para demostrarle a telecomunicaciones que
>es
>>> problema de red?
>>>
>>> Saludos.
>>
>> Mmm... no se, pues esto serian tiros a xiegas. Depronto un nmap desde
>afuera
>> y uno desde adentro de la red. Esto se podria tener en cuenta si tu
>server
>> es el unico que provee servicios a partir de una ip publica por que
>si hay
>> mas de uno ( que es lo mas normal) no seria de mucha ayuda.
>> Tambien depronto una trasa pero como digo. Con tan poca info es
>complucado y
>> a la final uno termina es divagando jejejeje.
>>
>>>
>>>
>
>
>
>--
>
>
>~ Happy install !
>
>
>Erick.
>
>---
>
>Cellphone : +51 950307809
>IRC : zerick
>About : http://about.me/zerick
>Linux User ID : 549567
>
>
>--
>To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmaster@lists.debian.org
>Archive:
>https://lists.debian.org/CADOnD36YEv8boUdQN+h9NT+nZE=cWfpfrL5uTWcO96sFyw@mail.gmail.com
>
>
>--
>To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmaster@lists.debian.org
>Archive:
>[🔎] 1394839233.41943.YahooMailNeo@web160902.mail.bf1.yahoo.com">https://lists.debian.org/[🔎] 1394839233.41943.YahooMailNeo@web160902.mail.bf1.yahoo.com
No parece que haya errores en el interfaz de red, aunque quizás quieras verificarlo con ifconfig.
Supongo revisaste las reglas [0] del firewall local (del propio host) para ver que nada está bloqueando el tráfico (por número de conexiones, cantidad de tráfico por tiempo, interpretación de bruteforcing y consecuente bloqueo -p.ej. fail2ban-...).
Cuando te pase ésto podrias lanzar un tcpdump tanto en el host cliente (desde el que hagas el request http) como en el servidor [1] y a ver qué ves en el tráfico (llega al servidor? vuelve a cliente?).
[0] iptables -L -vn
[1] tcpdump -ni <interfaz> host <ipcliente> and host <ipservidor> and port 80
Salut,
jors
--
S'ha enviat des del meu telèfon Android amb K-9 Mail. Si us plau, excusa la meva brevetat.
Reply to: