Smokeping y su modulo TCPPing no generan datos [Resuelto]

A los usuarios de esta aplicación de monitoreo les puede servir este dato:
Smokeping suele usar paquetes ICMP para revisar latencia y disponibilidad, sin embargo posee un módulo llamado TCPPing para revisar disponibilidad en base a conexiones TCP, para ello debes obtener el script tcpping, pero ademas de eso, debes instalar tcptraceroute, de otra forma tcpping no funciona como es debido y smokeping jamás generará una gráfica basandose en su modulo.

Instala tcptraceroute y ejecuta update-alternatives --display tcptraceroute

¿Este modulo sirve para verificar disponibilidad de servicios?

Definitivamente NO, ya que lo que hace es tomar los tiempos de respuestas de cualquier paquete TCP que reciba como respuesta, es decir, si lo apuntas al puerto 80 tcp y hay un servidor web a la escucha, tcptraceroute arrojará como resultado una grafica usando flags SYN ACK, sin embargo si lo apuntas a un puerto que no cuenta con ningún servicio, tcptraceroute tomará como referencia el tiempo de respuesta del un paquete flags RST ACK que indica que no hay respuesta, pero aun asi ese flag arroja un tiempo que indica que algo respondió al otro lado.

Prueba a servicio existente:

Selected device lo, address 200.1.22.6, port 35194 for outgoing packets
debug: pcap filter is: (nothing)
Tracing the path to 200.1.22.6 on TCP port 80 (www), 30 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 3 for hop 1, IP ID 20312, source port 35194, SYN
debug: received 40 byte IP packet from pcap_next()
debug: Received TCP packet
debug: Received TCP packet 200.1.22.6:35194 -> 200.1.22.6:80, flags SYN
debug: Ignoring TCP which doesn't match the correct port numbers
debug: received 44 byte IP packet from pcap_next()
debug: Received TCP packet
debug: Received TCP packet 200.1.22.6:80 -> 200.1.22.6:35194, flags SYN ACK
debug: displayed hop
1 servicios.santiago.utfsm.cl (200.1.22.6) [open] 0.135 ms

Prueba a servicio inexistente

Tracing the path to 200.1.22.6 on TCP port 14919, 30 hops max
debug: Generating a new batch of 512 IP ID's
debug: Sent probe 1 of 3 for hop 1, IP ID 21560, source port 46045, SYN
debug: received 40 byte IP packet from pcap_next()
debug: Received TCP packet
debug: Received TCP packet 200.1.22.6:46045 -> 200.1.22.6:14919, flags SYN
debug: Ignoring TCP which doesn't match the correct port numbers
debug: received 40 byte IP packet from pcap_next()
debug: Received TCP packet
debug: Received TCP packet 200.1.22.6:14919 -> 200.1.22.6:46045, flags RST ACK
debug: displayed hop
1 servicios.santiago.utfsm.cl (200.1.22.6) [closed] 0.108 ms

Como verán, siempre hay un tiempo de respuesta y no hay nada que hacer, asi está hecho tcptraceroute, salvo modificarlo y recompilarlo. La unica forma sería usarlo para monitorear servicios tras firewall que apliquen DROP como política por defecto y no un REJECT

¿Como funciona cada prueba?

El sentido de dependencia es el siguiente:

smokeping ➡ Modulo TCPPing ➡ tcpping ➡ tcptraceroute

Al final, todo se basa en la respuesta de tcptraceroute

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x