Conviene reconocer procesos y servicios. Todas las pruebas deben limitarse a tu laboratorio o a sistemas autorizados.
CONTENIDO ORIGINAL
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
ANTES DE EMPEZAR
Ubícate antes de avanzar
Al terminar deberías poder relacionar Direcciones y rutas con Sockets y puertos y resolver un caso nuevo.
Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.
04 / PREPARA EL LABORATORIO
Prepara una máquina virtual Linux con red NAT e instantáneas, o WSL para las prácticas que no requieren kernel y systemd completos.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan Direcciones y rutas y Sockets y puertos? ＋
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Seguirás una conexión desde interfaz y ruta hasta DNS, puerto, TLS y aplicación, usando laboratorios autorizados y pruebas que responden una sola pregunta.
Al terminar podrás
- Dirección, ruta, nombre y puerto son preguntas diferentes
- Escuchar en 127.0.0.1 no equivale a escuchar en todas las interfaces
- Cifrado, identidad y aplicación se verifican por separado
01
Modelo por capas
Dirección, ruta, nombre y puerto son preguntas diferentes
ip address muestra identidades de interfaz; ip route decide el próximo salto; DNS traduce nombres; TCP o UDP identifican conversaciones por puertos; la aplicación define el protocolo superior. Un ping fallido no demuestra que un servicio web esté caído y un DNS correcto no demuestra que el puerto escuche.
La ruta más específica suele ganar.
localhost y una dirección externa prueban caminos distintos.
IPv4 e IPv6 deben diagnosticarse por separado cuando ambos existen.
Si getent resuelve un nombre, ¿qué has demostrado?
Mostrar respuesta ＋
Solo que el sistema obtuvo una o más direcciones para ese nombre; todavía falta probar ruta, puerto, TLS y respuesta de aplicación.
02
Sockets y alcance
Escuchar en 127.0.0.1 no equivale a escuchar en todas las interfaces
Un socket servidor se enlaza a dirección y puerto. 127.0.0.1 o ::1 aceptan tráfico local; 0.0.0.0 o :: pueden incluir interfaces externas según firewall. ss muestra listeners y conexiones. Netcat sirve para pruebas simples dentro de un entorno autorizado, pero no reemplaza comprender el protocolo.
Un puerto abierto identifica un listener, no su legitimidad.
Firewall, red y aplicación pueden fallar por separado.
Un escaneo requiere alcance y autorización explícitos.
¿Qué indica un listener en 0.0.0.0:8080?
Mostrar respuesta ＋
Que el proceso solicitó escuchar en todas las interfaces IPv4 disponibles; firewall y rutas todavía pueden impedir accesos externos.
03
TLS y evidencia
Cifrado, identidad y aplicación se verifican por separado
TLS cifra la sesión y autentica el nombre mediante una cadena de certificados, pero una conexión TLS válida no garantiza que la aplicación entregue el recurso correcto. openssl s_client permite observar negociación; curl muestra DNS, conexión, certificado, cabeceras y estado HTTP.
El nombre solicitado debe coincidir con el certificado.
La hora del equipo afecta la validación.
No desactives la verificación como solución permanente.
¿Por qué curl -k no corrige un error de certificado?
Mostrar respuesta ＋
Porque solo omite una comprobación de seguridad; no repara identidad, cadena, fecha ni configuración y puede ocultar una interceptación.
Tu recorrido en tres ideas
- Dirección, ruta, nombre y puerto son preguntas diferentes
- Escuchar en 127.0.0.1 no equivale a escuchar en todas las interfaces
- Cifrado, identidad y aplicación se verifican por separado
Explica una web inaccesible por capas
Une interfaz, ruta, DNS, socket, TLS y HTTP sin saltar a conclusiones desde una única herramienta.
CASO
El nombre resuelve y el servicio funciona desde el servidor, pero otro equipo no logra abrirlo.
Procedimiento
- Compara dirección y ruta desde cliente y servidor.
- Observa bind del listener y política de firewall.
- Valida certificado, nombre y respuesta HTTP desde el cliente afectado.
Evidencia mínima
- Dirección resuelta y ruta elegida.
- Socket con dirección de escucha.
- Transcripción TLS y código HTTP o error exacto.
Mostrar razonamiento modelo ＋
Un servicio enlazado a loopback funciona localmente y falla fuera. Corregir bind puede ser necesario, pero solo junto con firewall y autorización del alcance.
Para ir más lejos¿Cómo cambia el diagnóstico si IPv6 resuelve primero pero el servicio solo escucha IPv4?
CIERRE DE LA SECCIÓN
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Concluir que internet funciona o falla usando solo ping.
Escanear redes ajenas o sin un alcance y autorización explícitos.
Ahora hazlo sin guía
Explica por capas por qué un nombre resuelve pero HTTPS no responde, usando una evidencia distinta para cada hipótesis.
Mostrar pauta de corrección ＋
Una respuesta sólida:
- Separa interfaz, ruta, DNS, puerto, TLS y HTTP.
- Identifica escucha local frente a externa.
- No desactiva controles de certificado como solución.