el corte, con hora: 93 minutos — y en un servicio que ya autoriza no va límite por tasa

Del `access.log`, sin ambigüedad. La IP del usuario (`45.234.61.160`, autenticada como `sergio`,
2709 peticiones) tuvo tres silencios: **93,2 min (11:59:37 → 13:32:49 UTC)**, 50,1 min (10:44:58 →
11:35:06) y 10,0 min (11:45:06 → 11:55:05). Los tres son el `timeout` de 10 minutos del ban
disparándose una y otra vez: cada vez que volvía, su primera ráfaga lo baneaba de nuevo. El corte
grande terminó exactamente cuando vacié los sets.

🧨 Y LA EXENCIÓN QUE TENÍA NO SERVÍA: la ACL histórica de squid exime `45.234.60.0/24` y él entra
desde `45.234.61.160` — **una red de al lado**. Parecía cubierto y no lo estaba. La pertenencia se
MIDE (`ip in red`), no se deduce del parecido del prefijo.

DECISIÓN DE FONDO: en un servicio que YA AUTORIZA no va límite por tasa. El uso de esta caja es
INTENSIVO —varias sesiones de agente en paralelo, cada una abriendo túneles a la vez— y un límite
calibrado para «una persona normal navegando» no protege de nada: el atacante ajusta su ritmo, el
usuario no puede trabajar más despacio. Squid ya pide usuario y contraseña y tiene su ACL. El ban del
puerto queda apagado (60000/min, ráfaga 1000) y contra un flood queda el tope GLOBAL
`syn_nuevas_por_seg`, que no distingue usuarios ni banea a nadie por ser rápido.

Control tras aplicar: su túnel pasando —`45.234.61.160 … CONNECT api.anthropic.com:443 sergio`— y
`45.234.61.160 ∈ 45.234.60.0/23` comprobado con aritmética de redes, no a ojo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/28-servidor-de-produccion.md

@@ -1928,6 +1928,35 @@ nuevos no llegaban a evaluarse nunca. Se vio contando (`grep -c dport` daba 30 y
 qué `saddr` salía primero. Por eso `cortafuegos apply-input` **borra la tabla antes de cargar** —
 usar `nft -f` a pelo se saltea esa mitad.
 
+#### La hora exacta, reconstruida del `access.log`
+
+El usuario preguntó a qué hora se bloqueó, y el log lo dice sin ambigüedad. Su IP —`45.234.61.160`,
+autenticada como `sergio`, **2709 peticiones**— tuvo estos silencios:
+
+| silencio | desde | hasta |
+|---:|---|---|
+| **93,2 min** | 16-09 **11:59:37** UTC | **13:32:49** UTC ← cuando vacié los sets |
+| 50,1 min | 10:44:58 | 11:35:06 |
+| 10,0 min | 11:45:06 | 11:55:05 |
+
+Los tres son el **`timeout` de 10 minutos del ban disparándose una y otra vez**: cada vez que volvía,
+su primera ráfaga lo baneaba de nuevo. `154.197.1.2`, que usa el proxy de forma sostenida pero sin
+ráfagas, sólo perdió huecos de 5 minutos.
+
+🧨 **Y la exención que tenía no servía: su IP no estaba en la red eximida.** La ACL histórica de squid
+exime `45.234.60.0/24` y él entra desde `45.234.61.160` — **una red de al lado**. Parecía cubierto y
+no lo estaba: la pertenencia se MIDE (`ip in red`), no se deduce del parecido del prefijo. Con el
+`/23` que nft dedujo al unir los dos `/24`, ahora sí.
+
+#### Y la decisión de fondo: en un servicio que YA AUTORIZA, no va límite por tasa
+
+El uso real de esta caja es **intensivo** —varias sesiones de agente en paralelo, cada una abriendo
+túneles a la vez—, y un límite calibrado para «una persona normal navegando» no protege de nada: el
+atacante ajusta su ritmo, el usuario no puede trabajar más despacio. Squid ya pide usuario y
+contraseña y tiene su ACL; el ban por tasa ahí no agrega seguridad, agrega cortes. Queda apagado
+(60000/min, ráfaga 1000: números que ningún cliente real alcanza) y contra un flood queda el tope
+GLOBAL `syn_nuevas_por_seg`, que no distingue usuarios ni banea a nadie por ser rápido.
+
 #### Lo que esto enseña del cortafuegos como herramienta
 
 Un cortafuegos correcto y un cortafuegos usable no son lo mismo, y la diferencia **no se ve al

scripts/servidor/cortafuegos-entrada.ron

@@ -51,6 +51,12 @@
         "201.209.132.56", "201.211.110.96", "181.225.47.111",
         "186.167.0.0/16", "190.72.0.0/16", "190.74.0.0/16", "190.77.0.0/16",
         "45.234.60.0/24",
+        // ⚠ `45.234.61.0/24` TAMBIÉN, y esto es lo que causó el corte del 16-09: el usuario entra
+        // desde `45.234.61.160` —autenticado como `sergio`, 2709 peticiones— y la ACL de squid sólo
+        // exime al `.60.0/24`. Una IP de al lado no es la misma red: estuvo **93 minutos sin proxy**
+        // (11:59→13:32 UTC) más dos cortes previos de 50 y 10 minutos, que son el `timeout` de 10
+        // minutos del ban disparándose una y otra vez.
+        "45.234.61.0/24",
     ],
     drop_estados_invalidos: true,
     icmp_echo_por_seg: 10,
@@ -113,13 +119,21 @@
             // fuente DESCONOCIDA, no un control de uso. Los usuarios de verdad están en
             // `confiables` y no llegan nunca a esta regla. Con 300/min y `burst 5` se baneaba solo
             // un cliente normal.
-            nuevas_por_min: 1200,
             ban_timeout_seg: 60,
-            // ⚠⚠ LA RÁFAGA ES LO QUE LO ROMPIÓ, no la tasa. `limit rate over N/minute burst 5`
-            // banea a quien abre 6 conexiones DE GOLPE aunque su promedio sea bajísimo, y un agente
-            // o un navegador detrás de un proxy abre decenas. Medido: `154.197.1.2` —autorizado, con
-            // contraseña— terminó en `@ban4` y perdió el proxy entero.
-            rafaga: 200,
+            // ⚠⚠ EL BAN POR TASA EN ESTE PUERTO ESTÁ EFECTIVAMENTE APAGADO, y es una decisión:
+            //
+            //   · El servicio ya AUTORIZA: squid pide usuario y contraseña y tiene su propia ACL.
+            //     Un ban por tasa no agrega seguridad, agrega falsos positivos.
+            //   · El uso real de esta caja es INTENSIVO —varias sesiones de agente en paralelo, cada
+            //     una abriendo túneles a la vez—, y un límite calibrado para «una persona normal
+            //     navegando» no le sirve a nadie acá. Medido el 16-09: con 300/min y `burst 5`, el
+            //     usuario principal perdió el proxy 93 minutos seguidos.
+            //   · Lo que SÍ queda contra un flood es el `syn_nuevas_por_seg` global de arriba, que
+            //     no distingue usuarios y no puede banear a nadie por ser rápido.
+            //
+            // El tipo exige > 0, así que se apaga con números que ningún cliente real alcanza.
+            nuevas_por_min: 60000,
+            rafaga: 1000,
         ),
     ],
 )