CMS v2.23.0 SAL Panel v1.0.364 SAL
Mail Soporte
Iniciar sesión

Bloqueos de Cloudflare (LaLiga): paso automático a conexión directa

La conmutación automática ante bloqueos de Cloudflare de MuseDock CMS mantiene tus webs visibles cuando las operadoras de un país bloquean IPs de Cloudflare, o cuando el propio Cloudflare deja de responder. Lo hace solo: detecta qué IPs han dejado de responder, quita la nube naranja (el proxy) de los dominios afectados para que vayan directos a tu servidor y, cuando la IP vuelve a funcionar de forma estable, vuelve a ponerla.

Viene integrado en el núcleo del CMS (no es un módulo aparte) y se configura en Ajustes → Bloqueos Cloudflare.

No es un escudo. Quitar el proxy de Cloudflare tiene un coste: mientras dura el bloqueo, tu web pierde la protección y la caché de Cloudflare, y la IP de tu servidor queda a la vista. Es un riesgo que se asume a propósito, porque es la única forma de que tu web siga viéndose en el país del bloqueo. Por eso se hace solo cuando hace falta, solo en los dominios afectados, el menor tiempo posible, y con la protección de fail2ban de MuseDock como refuerzo.

El problema: bloqueos de IPs compartidas

Cloudflare no da una IP a cada web: muchas webs comparten las mismas. En España, por orden judicial, las operadoras (Movistar, Orange, Vodafone, Digi…) bloquean durante los partidos de fútbol las IPs de Cloudflare donde LaLiga detecta retransmisiones piratas. Como esas IPs son compartidas, también caen todas las webs legales que las usan, aunque no tengan nada que ver con el fútbol.

Desde dentro del país, el visitante ve un error de conexión (ERR_CONNECTION_TIMED_OUT, «tardó demasiado en responder»). Desde fuera, la web funciona con normalidad. En los planes normales de Cloudflare no se pueden elegir otras IPs: la única forma de seguir visible es quitar el proxy mientras dura el bloqueo.

Cómo funciona

  1. Inventario. El CMS lee de Cloudflare los registros DNS de sus dominios (tenants, alias y redirecciones) con las cuentas de Cuentas DNS, y anota cuáles tienen la nube naranja y con qué IPs de Cloudflare responden.
  2. Sondas. Una o varias máquinas en el país que quieres vigilar (las sondas) prueban cada minuto si llegan a esas IPs, por cada conexión a internet que tengan (por ejemplo, dos operadoras distintas), y envían el resultado al CMS.
  3. Decisión. Si una IP falla dos informes seguidos desde alguna operadora, se da por bloqueada. Antes de cambiar nada, la sonda comprueba que tu servidor responde directo, sin Cloudflare, y con un certificado válido.
  4. Cambio. Se quita la nube naranja de los registros afectados (TTL de 60 s) y se guarda una foto de cómo estaban.
  5. Vuelta atrás. Cuando la IP lleva un tiempo (30 minutos por defecto) respondiendo desde todas las sondas, se vuelve a poner el proxy.

El CMS también comprueba la IP desde su propio servidor: si desde ahí responde, el aviso dice que es un bloqueo de operadoras; si no responde desde ningún sitio, que es una caída de Cloudflare. En los dos casos se actúa igual.

Reglas que nunca se rompen

  • Solo se toca lo que tenía el proxy puesto cuando empezó el bloqueo. Un dominio que ya iba sin proxy nunca entra en el ciclo, así que nunca se le pone.
  • Se respetan los cambios manuales. Al volver, el proxy solo se pone si el registro sigue exactamente como lo dejó el sistema. Si alguien lo cambió entretanto (desde Cloudflare, el Domain Manager o un cliente), se respeta y se avisa.
  • Ante la duda, quieto. Si ninguna sonda ha informado en los últimos 5 minutos, no se cambia nada.
  • Sin servidor sano no hay cambio. Si tu servidor no responde directo con un certificado válido, el dominio se deja como está: quitar el proxy lo empeoraría.
  • Las sondas no tienen las claves de Cloudflare. Solo informan; quien cambia el DNS es el CMS.

Modos

ModoQué hace
ApagadoNo quita el proxy a nada. Si había cambios hechos, sigue deshaciéndolos cuando la IP vuelve.
SimulaciónDetecta y avisa de lo que haría, sin tocar Cloudflare. Recomendado para empezar.
AutomáticoQuita y vuelve a poner el proxy solo, y avisa por correo de cada cambio.

Puesta en marcha

Requisitos

  • Tus dominios en Cloudflare, con su cuenta dada de alta en Ajustes → Cuentas DNS. El token necesita permiso para leer zonas y editar registros DNS.
  • Una máquina en el país que quieres vigilar, con Python 3 y curl, conectada por la operadora o las operadoras de tus visitantes. Sirve un servidor de la oficina, un miniPC o una Raspberry Pi.
  • Para vigilar varias operadoras desde la misma máquina, una interfaz de red por cada una y permisos de root, para poder elegir la salida.
  • Que tu servidor tenga certificado propio para cada dominio (por ejemplo, Let's Encrypt). Un certificado de origen de Cloudflare solo vale detrás del proxy.

1. Crear la sonda en el CMS (aquí se crea su acceso a la API)

En Ajustes → Bloqueos Cloudflare → Sondas, escribe un nombre (por ejemplo, el de la máquina) y pulsa Crear sonda. El CMS genera un token que es la llave de la sonda para su API:

  • Aparece una sola vez: cópialo en ese momento. El CMS solo guarda su huella.
  • Solo vale para dos llamadas: GET /api/v1/edge-guard/targets (qué IPs probar) y POST /api/v1/edge-guard/report (entregar resultados). No da acceso a nada más.
  • Si lo pierdes, crea la sonda otra vez con el mismo nombre: el token anterior deja de valer. Desde la misma lista puedes revocarla.

2. Preparar la máquina de la sonda

Sirve cualquier Linux en el país que quieres vigilar (un servidor de la oficina, un miniPC, una Raspberry Pi) con Python 3 y curl, conectado por la operadora o las operadoras de tus visitantes. Si quieres vigilar varias operadoras desde la misma máquina, cada una tiene que entrar por su propia interfaz de red. Para saber cómo se llaman:

ip -br addr        # nombres de las interfaces y sus IPs (eth0, eth1, enp3s0…)
ip route           # por qué puerta de enlace sale cada una

Para comprobar que cada interfaz sale por su operadora, mira la IP pública que tiene cada una:

curl --interface eth0 https://api.ipify.org
curl --interface eth1 https://api.ipify.org

3. Instalar la sonda

Descarga el script con el botón Descargar sonda de la pantalla, o desde la propia máquina:

curl -fsS https://tu-cms.example/api/v1/edge-guard/probe.py -o /usr/local/bin/musedock-edge-probe.py
chmod 755 /usr/local/bin/musedock-edge-probe.py

El script no lleva ningún dato tuyo: todo lo que cambia de una instalación a otra va en dos ficheros. Guarda el token (y solo el token) en un fichero que solo pueda leer root:

install -m 600 /dev/null /etc/musedock-edge-probe.token
nano /etc/musedock-edge-probe.token      # pega el token y guarda

Y crea la configuración, /etc/musedock-edge-probe.conf:

URL=https://tu-cms.example
TOKEN_FILE=/etc/musedock-edge-probe.token
PATHS=Operadora1:eth0,Operadora2:eth1
RESOLVE=10.66.0.1
OpciónQué poner
URLLa dirección de tu MuseDock CMS, la misma con la que entras al panel.
TOKEN_FILEEl fichero del token (permisos 600).
PATHSCada salida a internet que quieres vigilar, como nombre:interfaz, separadas por comas. El nombre es libre (sale así en la pantalla). Si la máquina solo tiene una conexión, borra la línea: se usará la salida por defecto.
RESOLVERecomendado: la IP privada de tu CMS dentro de una VPN, para que la sonda pueda avisar aunque la IP de Cloudflare de tu propio CMS esté bloqueada. Cómo montarla: conectar la sonda al CMS por WireGuard. Sin VPN, borra la línea.
CONTROLOpcional. Web de control para saber que la salida tiene internet (por defecto, una de Google). Si falla, el informe de esa salida no cuenta.

4. Probarla a mano

python3 -I /usr/local/bin/musedock-edge-probe.py -v

Verás una línea por salida, con su IP pública, cuántas IPs ha probado y cuáles no responden, y al final «Informe entregado al CMS». Por ejemplo, durante un bloqueo:

[Operadora1] interfaz=eth0 ip_publica=203.0.113.10 control=ok objetivos=42 fallan=2
    no responde: cf:188.114.96.3 (código 000)
    no responde: cf:188.114.97.3 (código 000)
[Operadora2] interfaz=eth1 ip_publica=198.51.100.20 control=ok objetivos=42 fallan=2
    …
Informe entregado al CMS: {"ok":true,"stored":87}

Si sale HTTP 401, el token no es correcto; si sale HTTP 000, la sonda no llega al CMS (revisa URL y RESOLVE); si sale HTTP 429, es que acababa de entregar otro informe hace menos de 20 segundos, y es normal.

5. Dejarla funcionando cada minuto

echo '* * * * * root flock -n /run/musedock-edge-probe.lock python3 -I /usr/local/bin/musedock-edge-probe.py' > /etc/cron.d/musedock-edge-probe

Va como root porque elegir la interfaz de salida lo necesita. Si algo falla, el cron te lo deja en el correo de root o en su registro.

6. Comprobar y activar en el CMS

En un par de minutos la sonda aparece como viva en la pantalla, con la IP pública de cada salida. Pulsa Leer Cloudflare si quieres el inventario al momento (se refresca solo cada 30 minutos). Déjalo en Simulación unos días y, cuando veas que los avisos aciertan, pásalo a Automático.

En el servidor del CMS, el vigilante corre cada minuto con el cron del sistema:

* * * * * php /ruta/del/cms/cli/cron-edge-guard.php >> /ruta/del/cms/storage/logs/cron-edge-guard.log 2>&1

Para ver el estado desde la terminal: php cli/cron-edge-guard.php --status.

La pantalla

  • Resumen arriba: qué está pasando ahora (todo normal, dominios sin proxy por bloqueo, simulación…).
  • Sondas: cada salida con su IP pública y la hora del último informe.
  • IPs de Cloudflare: el estado de cada IP (Responde, Bloqueada, Fallo puntual, Volviendo) y qué dominios cuelgan de ella. Se actualiza sola cada minuto.
  • Tus dominios en Cloudflare: la configuración original de cada nombre (con o sin proxy) y cómo está ahora.
  • Cambios y registro: el historial completo. El botón Vaciar registro borra lo cerrado y conserva los cambios activos, que hacen falta para deshacerlos.
  • Nunca tocar estos dominios: lista de exclusiones (incluye sus subdominios).

Cambiar a mano la configuración original

En Tus dominios en Cloudflare, pulsa el badge de la columna «Configuración original» (Con proxy o Sin proxy) para cambiarla. Se abre una ventana que explica qué va a pasar exactamente y pide tu contraseña. El sistema respeta esa nueva configuración desde ese momento, también en los bloqueos siguientes.

El cambio es inteligente: tiene en cuenta si hay un bloqueo en curso.

CambioSin bloqueoCon bloqueo en curso
De «sin proxy» a «con proxy»Se pone la nube naranja al momento.Si la zona del dominio tiene IPs de Cloudflare bloqueadas, sigue directo y queda pendiente: se le pone el proxy él solo cuando acabe el bloqueo, igual que a los demás.
De «con proxy» a «sin proxy»Se quita la nube naranja al momento.Si ya va directo por el bloqueo, no se toca Cloudflare: se anula el regreso y, al acabar, no se le vuelve a poner el proxy.

Para saber si un dominio sin proxy caería en una IP bloqueada, se miran las IPs de los demás nombres de su zona, porque Cloudflare suele dar las mismas a toda la zona. Si la zona no tiene otro nombre con proxy, se pone el proxy y, si le tocara una IP bloqueada, el sistema lo detecta en uno o dos minutos y lo quita hasta que pase. Cada cambio manual queda en el registro con quién lo hizo.

El riesgo de ir sin proxy y cómo lo compensa MuseDock: fail2ban

Con la nube naranja puesta, los ataques chocan primero con Cloudflare. Sin ella, llegan directos a tu servidor. Para cubrir ese hueco, MuseDock combina el CMS con fail2ban, que banea en el cortafuegos a las IPs que atacan:

  • Logins fallidos (superadmin, administradores de tenant, clientes y códigos 2FA): 8 fallos en 10 minutos desde una IP → bloqueo de 1 hora.
  • Escáneres que buscan ficheros que ningún visitante pide (/.env, /.git, wp-login.php en sitios sin WordPress, *.php sueltos…): 10 intentos en 5 minutos → bloqueo de 24 horas.
  • Reincidentes: el bloqueo crece con cada vuelta.
  • Funciona con y sin Cloudflare: corta en el cortafuegos (iptables) a quien conecta directo y en el servidor web (Caddy) a quien llega por Cloudflare.

Sé realista: fail2ban frena a quien prueba contraseñas o escanea tu web, pero no sustituye la protección de Cloudflare ante un ataque de denegación de servicio (DDoS) grande. Por eso la conexión directa dura solo lo que dura el bloqueo.

Qué viene de serie y qué no

PiezaDónde está¿De serie?
Conmutación automática ante bloqueos de CloudflareNúcleo de MuseDock CMSSí, en toda instalación del CMS. No es un módulo. Viene en modo Apagado hasta que la configuras.
Registro de eventos de seguridad (logins fallidos y escáneres)Núcleo de MuseDock CMS (storage/logs/security-events.log)Sí, siempre activo. Sin emails ni contraseñas; nunca anota IPs de Cloudflare ni privadas.
Jaulas de fail2ban que banean con ese registroMuseDock PanelSí, si el CMS está en un servidor gestionado con MuseDock Panel: se instalan solas al actualizar el panel.
fail2ban sin MuseDock PanelTu servidorNo: hay que instalar fail2ban y añadir las dos jaulas a mano (abajo tienes la configuración).

fail2ban sin MuseDock Panel

Si usas MuseDock CMS en tu propio servidor, instala fail2ban y crea estos dos filtros y sus jaulas. Cambia la ruta del registro por la de tu instalación.

# /etc/fail2ban/filter.d/musedock-cms-login.conf
[Definition]
failregex = ^ musedock-cms event=(?:login_failed|twofa_failed) ip=<HOST> host=\S+ path=\S+$
datepattern = ^%%Y-%%m-%%dT%%H:%%M:%%S(?:[+-]\d\d:\d\d)?

# /etc/fail2ban/filter.d/musedock-cms-probe.conf
[Definition]
failregex = ^ musedock-cms event=probe ip=<HOST> host=\S+ path=\S+$
datepattern = ^%%Y-%%m-%%dT%%H:%%M:%%S(?:[+-]\d\d:\d\d)?

# /etc/fail2ban/jail.d/musedock-cms.conf
[musedock-cms-login]
enabled  = true
filter   = musedock-cms-login
logpath  = /ruta/del/cms/storage/logs/security-events.log
port     = http,https
maxretry = 8
findtime = 600
bantime  = 3600

[musedock-cms-probe]
enabled  = true
filter   = musedock-cms-probe
logpath  = /ruta/del/cms/storage/logs/security-events.log
port     = http,https
maxretry = 10
findtime = 300
bantime  = 86400

Con el proxy de Cloudflare puesto, iptables no ve la IP real del atacante (ve la de Cloudflare). Para banear también a quien llega por Cloudflare hace falta un bloqueo en el servidor web o en Cloudflare; MuseDock Panel lo hace con su acción para Caddy. Mientras el dominio va directo por un bloqueo, iptables basta.

Seguridad

  • El token de una sonda solo permite dos cosas: pedir la lista de IPs que probar y entregar resultados. No da acceso al panel ni a los dominios.
  • El CMS solo acepta resultados de los objetivos que él pidió, y como mucho una entrega cada 20 segundos por sonda.
  • Un informe falso como mucho podría quitar un proxy un rato, y solo si tu servidor responde bien directo. Una sonda se revoca con un clic.
  • Las llamadas de las sondas no crean sesión ni cookies en el CMS.

Lo que hay que saber

  • Mientras dura el bloqueo, la IP de tu servidor queda a la vista y esos dominios pierden la caché y la protección de Cloudflare. Normalmente son un par de horas.
  • Los dominios de buckets R2 y de Workers no se pueden pasar a directo: solo funcionan a través de Cloudflare.
  • Solo se gestionan registros A y CNAME. Los AAAA (IPv6) con proxy se quedan como están.
  • Los cambios de DNS tardan lo que dura la caché de cada visitante (hasta 5 minutos en registros con proxy).
  • En un servidor réplica (base de datos de solo lectura) el vigilante no hace nada: decide el que manda.

Preguntas frecuentes

¿Solo sirve para el fútbol?

No. Mira lo que pasa de verdad, no el calendario: cubre cualquier bloqueo de IPs de Cloudflare en el país de la sonda y también las caídas del propio Cloudflare, siempre que tu servidor responda.

¿Afecta a los visitantes de otros países?

Los bloqueos de operadoras solo afectan a quien se conecta desde ese país. Cuando el sistema quita el proxy, los visitantes de fuera también van directos a tu servidor hasta que se restaura, y lo notan sin problemas.

¿Por qué unas IPs de Cloudflare funcionan y otras no?

Cada dominio usa su propia pareja de IPs de Cloudflare, y unas se comparten con muchas más webs que otras. Se bloquean las IPs concretas donde aparecen webs piratas; tus dominios en otras IPs siguen funcionando.

¿Puedo elegir otras IPs de Cloudflare en vez de quitar el proxy?

No en los planes Free, Pro y Business: Cloudflare asigna las IPs y no hay forma de pedir otras. Solo es posible con IPs dedicadas o BYOIP en Enterprise.

¿Qué pasa si cambio un registro a mano durante un bloqueo?

Al acabar, el sistema ve que el registro ya no está como lo dejó, no lo toca y te avisa. Tu cambio manda.

¿Necesito MuseDock Panel?

Para la conmutación, no: funciona solo con MuseDock CMS y una máquina que haga de sonda. Para el refuerzo con fail2ban, MuseDock Panel instala las jaulas solo; sin el panel puedes configurarlas a mano (ver fail2ban).

Solución de problemas

SíntomaCausa probable y solución
La sonda sale como «muda»No ha informado en 5 minutos. Ejecuta el cliente a mano (python3 -I /usr/local/bin/musedock-edge-probe.py): un error 401 indica token incorrecto; si no conecta, revisa URL y RESOLVE.
Todas las IPs salen «Sin datos»La web de control falla desde la sonda: la máquina no tiene internet por esa salida. Revisa el nombre de la interfaz en PATHS.
«El servidor de origen no responde directo con un certificado válido»Tu servidor no tiene certificado propio para ese dominio, o su cortafuegos solo deja entrar a Cloudflare. Hasta que lo arregles, ese dominio no se cambia.
Un dominio no apareceSolo entran los dominios del CMS cuyo DNS está en una cuenta de Cloudflare de Cuentas DNS. Pulsa Leer Cloudflare y revisa los errores de lectura.
Aún no veo la web tras quitar el proxyCaché DNS de tu equipo o router: espera unos minutos o reinicia el navegador.