linux – JJ0 https://digitalcore.space notas de pega/hobbies/otros Fri, 22 Aug 2025 14:22:11 +0000 es-CL hourly 1 https://wordpress.org/?v=6.8.2 Revisar sockets de red https://digitalcore.space/revisar-sockets-de-red/ https://digitalcore.space/revisar-sockets-de-red/#respond Fri, 22 Aug 2025 14:19:30 +0000 https://digitalcore.space/?p=20 Para revisar los sockets de red y sus conexiones en Linux, las herramientas principales son ss y, en sistemas más antiguos, netstat. El comando ss es la opción moderna y preferida por ser más rápido y eficiente.


Usando ss (Socket Statistics) nowoczesny

El comando ss es la herramienta estándar en los sistemas Linux modernos para investigar sockets. Es más rápido que netstat porque obtiene su información directamente del kernel 😉

Comandos básicos con ss

  • Listar todas las conexiones: Muestra todos los sockets TCP, UDP y UNIX.
ss -a
  • Listar solo sockets en modo “escucha” (Listening): Esto es muy útil para ver qué puertos están abiertos en tu sistema y esperando conexiones entrantes, como un servidor web o una base de datos.
ss -l
  • Mostrar el proceso/programa asociado a cada socket: Usando el parámetro -p, puedes ver qué aplicación está utilizando un puerto específico. Necesitarás privilegios de sudo para ver la información de todos los procesos.
sudo ss -p

Combinaciones útiles y ejemplos

La verdadera potencia de ss viene de combinar sus opciones. Aquí están las combinaciones más comunes y útiles:

  • La combinación más popular:
sudo ss -tulpn

Este es el comando que probablemente más usarás. Desglosemos qué hace cada opción:

  • -t: Muestra solo sockets TCP.
  • -u: Muestra solo sockets UDP.
  • -l: Muestra solo sockets en modo “escucha” (listening).
  • -p: Muestra el nombre del proceso.
  • -n: Muestra los números de puerto y direcciones IP en formato numérico, sin intentar resolver los nombres (lo que lo hace mucho más rápido).

Ejemplo de salida:

sudo ss -tulpn

State      Recv-Q Send-Q  Local Address:Port    Peer Address:Port   Process
LISTEN     0      4096    127.0.0.53%lo:53         0.0.0.0:* users:(("systemd-resolve",pid=1029,fd=14))
LISTEN     0      128       0.0.0.0:22         0.0.0.0:* users:(("sshd",pid=1543,fd=3))
LISTEN     0      128          [::]:22            [::]:* users:(("sshd",pid=1543,fd=4))

Interpretación:

  • El servicio systemd-resolve (para DNS) está escuchando en el puerto 53 de la dirección local 127.0.0.53.
  • El servicio sshd (para SSH) está escuchando en el puerto 22 en todas las interfaces IPv4 (0.0.0.0) e IPv6 ([::]).

Ver todas las conexiones TCP establecidas: Esto te permite ver quién está conectado a tu máquina y a qué te has conectado tú.

ss -tan state established

-t: TCP.

  • -t: TCP.
  • -a: Todas (established, listening, etc., pero lo filtramos con state).
  • -n: Numérico.
  • state established: Filtra solo por las conexiones que están completamente establecidas.
  • Filtrar por puerto específico: Puedes encontrar qué proceso está usando un puerto determinado.
sudo ss -tulpn | grep ':80'

Este comando te mostraría cualquier proceso que esté escuchando en el puerto 80 (HTTP).


Usando netstat (Network Statistics) 👴

En sistemas más antiguos o en algunos sistemas embebidos, ss podría no estar disponible, y en su lugar usarás netstat. Sus opciones son muy similares.

  • La combinación equivalente a ss -tulpn:
sudo netstat -tulpn

Las opciones (-t, -u, -l, -p, -n) significan exactamente lo mismo que en ss.

  • Listar todas las conexiones:
netstat -a

La principal diferencia es que ss es considerablemente más rápido, especialmente en sistemas con un gran número de conexiones, ya que no tiene que leer y procesar la misma cantidad de información que netstat.

]]>
https://digitalcore.space/revisar-sockets-de-red/feed/ 0
strace / ltrace https://digitalcore.space/strace-ltrace/ https://digitalcore.space/strace-ltrace/#respond Mon, 18 Aug 2025 18:26:55 +0000 https://digitalcore.space/?p=9 Para ver las llamadas al sistema (system calls), que son las solicitudes que un programa hace al kernel del sistema operativo para realizar tareas privilegiadas, existen diversas herramientas tanto de línea de comandos como con interfaz gráfica. Estas utilidades son fundamentales para la depuración de software, el análisis de rendimiento y la detección de problemas de seguridad.

¿Qué son las llamadas al sistema?

Antes de explorar las herramientas, es crucial entender qué es una llamada al sistema. Imagina que el kernel del sistema operativo es el “gerente/administrador” de todos los recursos de la computadora (hardware, memoria, archivos, etc.). Los programas de usuario no tienen acceso directo a estos recursos por razones de seguridad y estabilidad. Cuando un programa necesita abrir un archivo, conectarse a una red o crear un nuevo proceso, debe solicitarlo al kernel a través de una “llamada al sistema”. Estas herramientas nos permiten espiar esas solicitudes.


Herramientas para Linux

En el entorno de Linux, strace es la herramienta por excelencia para el rastreo de llamadas al sistema.

strace

Es una potente utilidad de línea de comandos que intercepta y registra las llamadas al sistema que un proceso realiza y las señales que recibe. Es increíblemente útil para diagnosticar por qué un programa falla o se comporta de manera inesperada sin necesidad de acceder al código fuente.

Características principales:

  • Fácil de usar: Simplemente se antepone strace al comando que se desea ejecutar.
  • Análisis en tiempo real: Muestra las llamadas al sistema a medida que se producen.
  • Adjuntar a procesos en ejecución: Puede adjuntarse a un proceso que ya está corriendo usando el pid (identificador de proceso).
  • Filtrado: Permite filtrar la salida para mostrar solo llamadas al sistema específicas, lo que facilita el análisis.
  • Información detallada: Muestra los argumentos de cada llamada al sistema y su valor de retorno.

Ejemplo de uso:

Para ver las llamadas al sistema del comando ls:

strace ls

Para adjuntarse a un proceso en ejecución (por ejemplo, con PID 1234):

strace -p 1234

ltrace

Similar a strace, ltrace rastrea las llamadas a bibliotecas compartidas en lugar de las llamadas directas al sistema. Esto es útil para entender cómo un programa utiliza las funciones de bibliotecas externas.


Herramientas para Windows

En Windows, el conjunto de herramientas de Sysinternals, ahora propiedad de Microsoft, ofrece las utilidades más potentes para este propósito.

Process Monitor (Procmon)

Es una herramienta avanzada de monitoreo con una interfaz gráfica que muestra en tiempo real la actividad del sistema de archivos, el registro de Windows y los procesos y subprocesos. Aunque no se limita solo a las llamadas al sistema, captura una gran cantidad de interacciones entre las aplicaciones y el sistema operativo que son el resultado de dichas llamadas.

Características principales:

  • Interfaz gráfica intuitiva: Facilita la visualización y el filtrado de la información.
  • Monitoreo exhaustivo: Captura una amplia gama of de eventos del sistema.
  • Filtrado avanzado: Permite crear filtros complejos para aislar eventos específicos.
  • Información detallada del evento: Proporciona detalles como la pila de llamadas (call stack) para identificar la causa raíz de una operación.
  • Registro de arranque: Puede registrar la actividad del sistema desde el inicio del arranque para diagnosticar problemas que ocurren en esa fase.

DTrace on Windows

DTrace, una herramienta de trazado dinámico originaria de Solaris y muy popular en sistemas tipo Unix (como macOS y FreeBSD), ha sido portada a Windows. Es una herramienta de línea de comandos muy potente y flexible para el análisis de rendimiento y la resolución de problemas a nivel de kernel y de aplicación.

Características principales:

  • Potencia y flexibilidad: Permite un análisis muy detallado y personalizado del sistema.
  • Bajo impacto: Diseñado para tener un impacto mínimo en el rendimiento del sistema que se está analizando.
  • Scripting: Utiliza un lenguaje de scripting (D) para definir qué y cómo se debe trazar.

Dr. Memory

Es un conjunto de herramientas para el análisis de memoria, pero incluye una utilidad llamada drstrace que funciona de manera similar a strace en Linux, permitiendo el rastreo de llamadas al sistema para una aplicación específica en Windows.

En resumen, la elección de la herramienta dependerá del sistema operativo y de la naturaleza del problema a diagnosticar. Para un análisis rápido y directo en Linux, strace es la opción ideal. En Windows, Process Monitor es la herramienta más accesible y completa para la mayoría de los usuarios.

usos mas comunes de strace y ltrace

Ver razonamiento

strace y ltrace son herramientas de diagnóstico para Linux que te permiten observar la interacción de un programa con el sistema, pero a diferentes niveles. strace rastrea las llamadas al sistema (peticiones al kernel), mientras que ltrace rastrea las llamadas a bibliotecas compartidas.

Aquí te explicamos sus usos más comunes de forma sencilla.


Usos comunes de strace

strace es tu herramienta de referencia cuando necesitas entender cómo un programa interactúa con el sistema operativo a bajo nivel. Es ideal para diagnosticar problemas sin necesidad de ver el código fuente.

Diagnosticar por qué un programa falla o se bloquea 🕵️‍♀️

Cuando una aplicación se cierra inesperadamente o no arranca, strace puede mostrarte la última acción que intentó realizar.

  • Problema típico: Un programa no inicia y no da ningún mensaje de error.
  • Cómo ayuda strace: Al ejecutar strace mi_programa, puedes ver si está intentando abrir un archivo de configuración que no existe (openat(...) = -1 ENOENT (No such file or directory)) o si no tiene permisos para leerlo (openat(...) = -1 EACCES (Permission denied)).

Encontrar problemas de permisos y archivos 📂

Es perfecto para descubrir qué archivos, directorios o sockets está intentando usar un programa.

  • Problema típico: Un servidor web como Nginx o Apache muestra un error “403 Forbidden” y no estás seguro de por qué.
  • Cómo ayuda strace: Puedes adjuntar strace al pid del proceso del servidor web (strace -p PID) y ver exactamente qué archivo está tratando de acceder y por qué falla. A menudo, el problema es simplemente un permiso incorrecto en la ruta del archivo.

Analizar el rendimiento de una aplicación 🐢

Si un programa funciona más lento de lo esperado, strace puede ayudarte a identificar cuellos de botella.

  • Problema típico: Una aplicación tarda mucho en procesar datos.
  • Cómo ayuda strace: La opción -c de strace (strace -c mi_programa) te ofrece un resumen estadístico de todas las llamadas al sistema: cuántas veces se llamó a cada una, el tiempo total empleado y los errores. Un número excesivo de llamadas read() o write() a un archivo podría indicar una E/S ineficiente.

Entender el comportamiento de la red 🌐

Puedes ver las conexiones de red que establece un programa.

  • Problema típico: No estás seguro a qué dirección IP o puerto se está intentando conectar una aplicación.
  • Cómo ayuda strace: Filtrando por llamadas de red como connect, accept, sendto, y recvfrom, puedes ver los detalles de las conexiones, incluyendo direcciones IP y puertos.

Usos comunes de ltrace

ltrace opera a un nivel más alto que strace. En lugar de mirar las peticiones al kernel, se enfoca en las funciones que un programa llama desde bibliotecas externas (archivos .so o shared objects).

Depurar problemas con bibliotecas compartidas 📚

Es la herramienta ideal cuando sospechas que un programa está usando incorrectamente una biblioteca o hay un problema de versiones.

  • Problema típico: Una aplicación falla con un error relacionado con una biblioteca específica (por ejemplo, OpenSSL, GTK, Qt).
  • Cómo ayuda ltrace: ltrace mi_programa te mostrará las funciones de la biblioteca que se están llamando, los argumentos que se les pasan y los valores que devuelven. Puedes ver si se está pasando un puntero nulo a una función que no lo espera o si una función devuelve un código de error que el programa no maneja.

Entender el flujo de ejecución de un programa 🧩

ltrace te permite seguir la lógica de la aplicación a un nivel más abstracto que strace.

  • Problema típico: Quieres entender cómo un programa utiliza una API específica proporcionada por una biblioteca sin tener que leer todo el código fuente.
  • Cómo ayuda ltrace: Puedes filtrar la salida para una biblioteca concreta (ltrace -l libcrypto.so mi_programa) y ver la secuencia de llamadas a funciones criptográficas, lo que te da una idea clara de cómo se está utilizando.

Identificar incompatibilidades de versiones de bibliotecas 🔄

A veces, un programa compilado para una versión de una biblioteca falla cuando se ejecuta con una versión diferente.

  • Problema típico: Una aplicación funciona en un sistema pero falla en otro después de una actualización.
  • Cómo ayuda ltrace: Puedes comparar la salida de ltrace en ambos sistemas. Quizás una función ha cambiado su comportamiento o ha quedado obsoleta en la nueva versión de la biblioteca, y ltrace te mostrará la llamada que está causando el problema.

¿Cuándo usar cuál?

  • Usa strace para problemas de interacción con el sistema operativo: archivos, permisos, red, procesos.
  • Usa ltrace para problemas de interacción con bibliotecas compartidas: uso incorrecto de funciones, errores de API, problemas de versiones.

A menudo, la mejor estrategia es usar ambas. Empieza con strace para ver si hay un problema a nivel de sistema. Si no encuentras nada obvio, pasa a ltrace para investigar cómo el programa está utilizando las bibliotecas.

Ejemplos para otros problemas de red.

Nota: La clave está en buscar llamadas al sistema relacionadas con la red, como socket, connect, bind, sendto, y recvfrom.


1. Conexión rechazada (Connection Refused) ⛔

Este es el problema más típico: intentas conectar con un servicio y la conexión es rechazada inmediatamente. strace te muestra exactamente a qué IP y puerto estás intentando conectar y el resultado.

El problema: Intentas usar curl para acceder a un servidor local en el puerto 8081, pero no hay nada escuchando allí. Recibes un error de “Connection refused”.

Comando strace:

strace -e trace=connect curl http://127.0.0.1:8081
  • -e trace=connect: Le decimos a strace que solo nos muestre la llamada al sistema connect.

Salida de strace (la parte importante):

connect(3, {sa_family=AF_INET, sin_port=htons(8081), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)

Análisis del resultado:

  • connect(3, ...): curl está intentando realizar una llamada connect en el descriptor de archivo 3 (que es un socket de red).
  • sin_port=htons(8081): Confirma que el puerto de destino es 8081.
  • sin_addr=inet_addr("127.0.0.1"): Confirma que la IP de destino es 127.0.0.1.
  • = -1 ECONNREFUSED (Connection refused): Esta es la clave. El kernel devolvió un error ECONNREFUSED, lo que significa que no hay ningún proceso escuchando en ese puerto en esa dirección IP. El problema no es un firewall que bloquea el paquete (eso daría un timeout), sino que el servidor de destino simplemente no está ahí.

2. Problemas de resolución de DNS 🌐

A veces, el problema no es la conexión en sí, sino que tu aplicación ni siquiera puede averiguar la dirección IP del dominio al que intenta conectar.

El problema: Intentas hacer ping a un dominio que no existe, como dominioinventado123.com.

Comando strace:

strace -e trace=connect,openat ping -c 1 dominioinventado123.com
  • Aquí rastreamos connect y también openat para ver qué archivos de configuración de red intenta leer.

Salida de strace relevante:

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
...
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = 0
...

Análisis del resultado:

  • openat(..., "/etc/resolv.conf", ...): El programa está abriendo /etc/resolv.conf. Esto te confirma qué servidor DNS está intentando usar (en este caso, el contenido de ese archivo apuntaría, por ejemplo, a 8.8.8.8).
  • connect(..., sin_port=htons(53), ...): Vemos que el programa se está conectando al puerto 53, que es el puerto estándar de DNS.
  • Si la conexión al servidor DNS falla (por ejemplo, por un firewall), verías aquí un ECONNREFUSED o un ETIMEDOUT. Si la resolución de nombres falla (como en este caso), la aplicación simplemente terminará con un error de “Name or service not known”, y strace te habrá mostrado el último intento de contacto con el servidor DNS.

3. Conexión lenta o Timeout ⏳

Un firewall que descarta paquetes (DROP) en lugar de rechazarlos (REJECT) es una causa común de timeouts. La aplicación intenta conectar, pero nunca recibe una respuesta.

El problema: Intentas conectar a una IP y puerto que están bloqueados por un firewall que silenciosamente descarta los paquetes.

Comando strace:

strace -e trace=connect nc -v -w 3 192.168.1.100 443
  • Usamos netcat (nc) con un timeout (-w 3) para no esperar indefinidamente.

Salida de strace:

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.168.1.100")}, 16) = -1 EINPROGRESS (Operation now in progress)
... (aquí no pasa nada por un largo tiempo) ...

Al final, tras el timeout de la aplicación, el proceso se rendirá. La llamada connect se queda “colgada”.

Análisis del resultado:

  • = -1 EINPROGRESS: Esto es normal para sockets no bloqueantes. La conexión se ha iniciado pero aún no se ha completado.
  • El problema aquí es la ausencia de una respuesta. A diferencia del ECONNREFUSED que es instantáneo, aquí la llamada se queda esperando. strace te muestra que el programa envió el paquete SYN para iniciar la conexión, pero nunca recibió una respuesta (SYN/ACK o RST). Esto apunta directamente a un problema de red intermedio, como un firewall o un problema de enrutamiento.

En resumen, al analizar la salida de connect en strace:

  • ECONNREFUSED: Rápido y claro. El servidor de destino está activo pero no hay nada en ese puerto.
  • ETIMEDOUT / Ausencia de respuesta (EINPROGRESS sin fin): Lento. Generalmente es un firewall o un problema de enrutamiento.
  • EHOSTUNREACH: El sistema ni siquiera sabe cómo enviar paquetes a esa dirección. Problema de enrutamiento local.

4. Ver el ciclo de vida completo de una conexión (TCP) ⛓

Para depurar una conexión TCP completa, desde su creación hasta el intercambio de datos y su cierre, necesitas rastrear más que solo el grupo %network.

El problema: Quieres ver cómo un cliente como curl establece una conexión, envía una petición HTTP y recibe la respuesta.

Comando strace:

strace -e trace=socket,connect,write,read,close curl https://www.google.com > /dev/null
  • socket: La creación del punto de comunicación (el socket).
  • connect: El intento de conexión al servidor remoto (https://www.google.com/search?q=google.com).
  • write: El envío de la petición HTTP a través del socket. Verás el GET /....
  • read: La recepción de la respuesta del servidor (el código HTML de la página).
  • close: El cierre de la conexión.

Nota: Esta combinación te da una visión cronológica y completa. Si curl se queda “colgado”, puedes ver si es después de connect (problema de red), después de write (esperando respuesta del servidor) o durante read (descarga lenta).


5. Diagnosticar problemas de espera o “cuelgues” (I/O) ⏳

Muchas aplicaciones de red no leen y escriben constantemente. En su lugar, esperan a que un socket esté listo para ser leído o escrito. Si tu programa se queda bloqueado, probablemente esté atascado en una de estas llamadas de “espera”.

El problema: Un servicio de red no responde a nuevas peticiones y parece estar bloqueado.

Comando strace:

strace -p PID -e trace=poll,select,epoll_wait
  • poll, select, epoll_wait: Estas son las tres llamadas al sistema principales que los programas usan para monitorear múltiples descriptores de archivo (como sockets de red) y esperar a que uno de ellos tenga datos para leer o esté listo para escribir.

Nota: Si la salida de strace muestra que el programa está constantemente en una de estas llamadas sin que nunca devuelva un evento, significa que está esperando datos que nunca llegan o que no hay clientes conectándose. Es una forma muy eficaz de confirmar que un proceso está inactivo y esperando por I/O (Entrada/Salida).


6. Ver todo el tráfico de datos (Lectura/Escritura) ✍

A veces solo te interesa ver los datos que se transfieren, no la configuración de la conexión. Para ello, puedes usar una combinación que filtre todo lo que no sea lectura y escritura en descriptores de archivo de red.

El problema: Quieres espiar los datos que una aplicación envía a través de una conexión ya establecida sin el “ruido” de otras llamadas al sistema.

Comando strace:

strace -p PID -e trace=read,write,sendto,recvfrom -s 1024
  • read, write: Llamadas genéricas para leer y escribir en descriptores de archivo, que incluyen sockets.
  • sendto, recvfrom: Específicas para comunicación sin conexión (como UDP), pero también muy comunes.
  • -s 1024: Aumenta el tamaño de la cadena que strace muestra. Por defecto, es muy corto (32 caracteres), por lo que es crucial aumentarlo para ver los datos de red reales.

Nota: Esta vista es útil para ingeniería inversa de protocolos simples o para verificar si los datos que tu aplicación cree que está enviando son correctos. Verás el contenido exacto de los paquetes que se mueven entre la aplicación y el kernel.

Resumen de Syscalls de Red para Trazas Específicas

ObjetivoSyscalls recomendadasCuándo usarla
Establecimiento de conexiónsocket, bind, connect, listen, acceptPara diagnosticar por qué una conexión no se establece.
Transferencia de datosread, write, sendto, recvfrom, sendmsg, recvmsgPara inspeccionar los datos que se envían y reciben.
Espera de eventos (I/O)poll, select, epoll_waitPara saber por qué una aplicación está “colgada” o no responde.
Resolución de DNSconnect (al puerto 53), openat (/etc/resolv.conf)Para depurar problemas de resolución de nombres de dominio.
Cierre de conexiónclose, shutdownPara confirmar que las conexiones se están cerrando correctamente.

Combinar estas llamadas específicas te da mucho más poder que simplemente usar el grupo %network por defecto 😉

]]>
https://digitalcore.space/strace-ltrace/feed/ 0