feat(episode): TRAZA_r11seccion1i1-causa-raz-el-servidor-desc_S20260814.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: AEGIS | Type: troubleshooting
Summary: EPISODIO 1 — MEMORIA: [R11.seccion1.I1] Causa raíz: el servidor descartaba conex

episodes/TRAZA_r11seccion1i1-causa-raz-el-servidor-desc_S20260814.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,49 @@
+---
+episode_id: "8029a191-a27c-48a1-8250-6b5b9083eeba"
+puente_flat: "TRAZA_r11seccion1i1-causa-raz-el-servidor-desc_S20260814.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260814.SHERPA_CLONACION_SERVIDOR"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "AEGIS"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — MEMORIA: [R11.seccion1.I1] Causa raíz: el servidor descartaba conexio"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-08-21T18:08:23.287337+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+## [R11.seccion1.I1] Causa raíz: el servidor descartaba conexiones **sin registrarlo**
+
+No era la red, ni un baneo, ni tu servidor cayéndose. El `sshd` corre con:
+
+Cuando más de 10 conexiones coinciden en fase previa a autenticación, sshd tira ~30% **por diseño**. Reproducido:
+
+| Patrón | Resultado |
+|---|---|
+| 8 secuenciales, 6s de separación | **8 OK / 0 fallo** |
+| 12 simultáneas | **12 OK / 0 fallo** |
+| **20 simultáneas** | **15 OK / 5 fallo (25%)** ← coincide con el 30% declarado |
+
+En esa ráfaga aparecieron **los tres mensajes** que veníamos viendo por separado (`Connection closed`, `kex_exchange_identification: reset`, `timed out during banner exchange`): son un solo fenómeno, no tres. **Por qué costó tanto:** sshd **no registra** esos descartes a nivel INFO. El log mostraba **0 rechazos en todo el día** mientras descartaba. Un sensor mudo se ve idéntico a un sistema sano. ## [R11.seccion2.T1] Ocho hipótesis muertas por evidencia
+
+| Hipótesis | Lo que la mató |
+|---|---|
+| Baneo CrowdSec | `No active decisions` |
+| Latencia/pérdida | TCP connect **0,21s**, 20/20 |
+| `ConnectTimeout=5` corto | el connect real son 0,21s |
+| Puertos efímeros agotados | **6%** en uso, 13 TIME_WAIT |
+| Servidor sobrecargado | load **1,17** con 16 vCPU |
+| Otra instancia compitiendo | una sola IP |
+| Cron de veredictos muerto | los 6 ficheros son **de hoy** |
+| Multiplexar (ControlMaster) | **no funciona** en Win32-OpenSSH |
+
+`★ Insight ─────────────────────────────────────`
+El error metodológico más instructivo fue mío: descarté `MaxStartups` en la primera vuelta porque **12 concurrentes pasaron limpias**. El control era demasiado débil — hacían falta 20 para cruzar el umbral. Un control negativo que no alcanza a provocar el fallo **no demuestra ausencia de causa**: demuestra que el control era flojo. Casi entierro la hipótesis correcta con evidencia insuficiente. `─────────────────────────────────────────────────`
+
+## [R11.seccion3.I2] Y el panel decía dos cosas, una falsa
+
+`"sin contacto ...