redes

Si me enviaran a una isla digital desierta y solo me permitieran llevar una utilidad de red, sin dudarlo elegiría Netcat.

La documentación oficial (man nc) dice secamente: «utilidad para leer y escribir a través de conexiones de red usando TCP o UDP».
En la práctica es la navaja suiza del ingeniero de red, que reemplaza a decenas de programas especializados.

En el artículo se usan ejemplos para OpenBSD netcat — es el que viene por defecto en Ubuntu 20.04+, Debian 10+, Fedora, Arch, Alpine y en la mayoría de las distribuciones modernas.

Read more

Cada vez que escribes google.com en el navegador, ocurre magia. Tu ordenador no sabe dónde está físicamente ese sitio. Para averiguarlo, consulta al DNS (Domain Name System) — una gigantesca base de datos distribuida, a menudo llamada “la agenda telefónica de Internet”.

Este libro consiste en registros, cada uno de los cuales le dice al mundo algo concreto sobre tu dominio: dónde está tu sitio, a dónde enviar el correo o cómo verificar que eres el propietario del dominio.

En un mundo donde la privacidad de los datos y el acceso a recursos a menudo están restringidos por geobloqueos o políticas corporativas, herramientas como ProxyChains se vuelven asistentes indispensables. ProxyChains —o más precisamente su fork moderno ProxyChains-NG— es una herramienta utilitaria de código abierto para sistemas tipo Unix (Linux, macOS, etc.) que permite redirigir el tráfico de red de cualquier aplicación a través de una cadena de servidores proxy. Es especialmente popular entre desarrolladores, pentesters y entusiastas de la seguridad. En este artículo analizaremos qué puede hacer ProxyChains, por qué es útil para desarrolladores, daremos ejemplos de uso y discutiremos sus limitaciones.

Este artículo está compilado como «chuleta» para redes SOHO/SMB: problemas frecuentes, sus síntomas, causas, soluciones rápidas y listas de verificación de diagnóstico. Sirve tanto para ingenieros como para administradores que mantienen el enlace MikroTik ↔ Keenetic.

📑 Navegación

• EoIP «se queda congelado» al transferir archivos grandes
• Site-to-Site VPN activo, pero el tráfico no circula
• NAT rompe VPN/EoIP
• MTU/MSS: cómo elegir correctamente
• Enrutamiento por políticas (RouterOS 7)
• SMB desde otra subred no funciona
• Lista de verificación de diagnóstico rápido
• Chuletas de comandos
• MTU típicos para túneles
• Matriz de excepciones NAT/Firewall
• Errores frecuentes
• Visualizaciones (PlantUML)
• Recursos y documentación

1) EoIP «se queda congelado» al transferir archivos grandes

Síntomas: SMB/FTP se queda colgado, la velocidad va a tirones, RDP se corta.
Causas: MTU/MSS incorrecto, fast-path con IPsec, errores de NAT/Firewall.

Introducción

Imagínese: ping funciona, DNS responde, los puertos están abiertos, mtr no muestra pérdidas, y curl devuelve errores como connection reset by peer o SSL handshake failed. El problema está ahí, pero las utilidades estándar son impotentes.

En esos momentos queda mirar el propio tráfico — es decir, “escuchar los cables”. Este proceso se llama packet sniffing o análisis de paquetes. En el artículo veremos cómo usar tres herramientas clave: tcpdump, sngrep y Wireshark.

Introducción

Hasta ahora habíamos usado utilidades sencillas para tareas concretas:

• ping verificaba la conectividad,
• traceroute mostraba la ruta,
• ipconfig y arp ayudaban con la red local,
• telnet y nc probaban puertos.

Es como tener un martillo, un destornillador y una llave por separado. Pero a veces se necesita una herramienta multifunción. Hoy veremos tres de esos “todoterreno”:

• mtr — ping y traceroute en esteroides,
• nmap — escáner de red universal,
• curl — un navegador en la línea de comandos.

mtr — Rastreo en tiempo real 🚀

¿Qué hace?

Combina las capacidades de ping y traceroute. Muestra en tiempo real la latencia y el porcentaje de pérdida de paquetes para cada nodo en la ruta.

Introducción

La dirección IP del servidor es como la dirección postal de un edificio de apartamentos. Pero para entrar en el piso correcto necesitas conocer el número de la puerta. En las redes, esas puertas son los puertos.

• HTTP funciona en el puerto 80.
• HTTPS — en el puerto 443.
• El correo, las bases de datos y otros servicios escuchan en sus propios puertos.

Si el puerto está cerrado o nadie responde en él, el sitio no se abrirá, incluso si el servidor está “vivo”.

Introducción

Has hecho todas las comprobaciones de artículos anteriores:

• El equipo tiene la dirección IP correcta (ipconfig).
• El router responde (ping 192.168.1.1).
• El ping a una dirección pública (ping 8.8.8.8) funciona.

Parece que Internet funciona, ¡pero en el navegador google.com no se abre. 🤔
Bienvenido a la causa más frecuente de este tipo de problemas: fallos de DNS.

¿Qué es el DNS? 📖

Internet opera con direcciones IP (por ejemplo, 142.250.184.110), pero a las personas les resulta más cómodo usar nombres (google.com).

Introducción

En el artículo anterior aprendimos a contactar servidores remotos con ping y a rastrear la ruta de los paquetes con traceroute. Pero, ¿qué pasa si ping google.com no responde y traceroute se interrumpe en el primer salto?

Esto es un claro indicio de que el problema está cerca: en tu equipo, en el cable de red o en el router doméstico. Antes de llamar al soporte técnico, revisemos nuestra propia red local.