Firewalls Hetzner — estado y topología de acceso

Estado consolidado tras el barrido de superficie externa (s219, 12-07-2026) y el endurecimiento de firewalls (s222, 14-07-2026). Fuente de verdad del modelo de acceso a los servidores Hetzner.

Servidores y direcciones

Server (mote)	ID Hetzner	IP pública	IP NetBird	Rol
`crearack-prod`	121377067	116.203.31.166	100.96.156.31	SaaS PROD (Dokploy)
`crearack-staging`	125976808	178.104.131.173	100.96.254.204	Testing (Dokploy que gestiona PROD)
`crearack-ops`	147434248	178.104.244.255	100.96.245.233	Runners CI + todos los crons
`DCA`	138659488	62.238.33.149	100.96.6.166	channelassistance.com (Flask+Nginx)

Firewalls (uno dedicado por server desde s222)

Firewall	ID	Aplicado a	Inbound permitido
`firewall-crearack-prod`	11295929	crearack-prod	22 (equipo) · 443 (solo rangos Cloudflare) · icmp · 3000 (equipo+GitHub)
`firewall-crearack-stage`	11306786	crearack-staging	22 (equipo) · icmp · 3000 (equipo+GitHub) — sin 80/443
`firewall-CreaRack`	10679994	crearack-ops	22 (equipo) · icmp · 3000 (equipo+GitHub) — sin 80/443
`firewall-dca`	11296012	DCA	22 (equipo) · 80 + 443 (solo rangos Cloudflare) · icmp

firewall-CreaRack era el firewall COMPARTIDO histórico (prod/staging/dca/ops). En s219 se sacaron prod y dca a firewalls dedicados; en s222 se sacó staging (nuevo firewall-crearack-stage) → hoy firewall-CreaRack cubre solo ops. El antiguo firewall-staging-8000 (puerto 8000 sin uso) se retiró en s222.

Modelo de acceso (el porqué de las reglas)

Puertos web del origen (:80/:443): solo abiertos donde hay web pública detrás de Cloudflare, y restringidos a los rangos oficiales de Cloudflare (nadie llega al origen saltándose CF). Aplica a prod (:443) y dca (:80+:443). PROD renueva el cert por dnsChallenge (por eso pudo cerrar el :80); DCA por DNS-01. staging y ops no sirven web → :80/:443 cerrados del todo.
SSH (:22) y panel Dokploy (:3000): restringidos a las IPs fijas del equipo — trabajo 37.34.68.35, sede 212.230.190.240, IP fija de Edu 91.126.184.163 (+ rangos de GitHub en :3000 para los webhooks de deploy).
Desde casa de Edu (IP dinámica, rango 93.176.0.0/16): el acceso admin va SOLO por NetBird (s222 quitó ese /16 de todos los firewalls — eran 65.536 IPs). Los 4 servers están en NetBird; SSH y Dokploy verificados por la IP 100.96.x. NetBird P2P es fluido para SSH y web (a diferencia de RDP, que sufre por la latencia del overlay).
ICMP (ping): abierto a 0.0.0.0/0 en todos (bajo riesgo, decisión consciente).

Cómo modificar un firewall

No hay token Hetzner permanente en la infra (se usa uno temporal de usar y tirar). Procedimiento: Edu genera un API token (console.hetzner.cloud → Security → API Tokens → Read & Write), Claude aplica el cambio por la API (/v1/firewalls/{id}/actions/set_rules reemplaza TODAS las reglas — leer + backup primero), y Edu revoca el token al terminar. La regla :3000 de Dokploy se filtra además por iptables DOCKER-USER en el propio server (no solo por el firewall Hetzner).

Historial

s219 (12-07-2026): cerrado el :443 directo de PROD y de DCA a solo-CF (vector F2 confirmado explotable). Firewalls dedicados firewall-crearack-prod y firewall-dca.
s222 (14-07-2026): PROD migrado a dnsChallenge y :80 cerrado · STAGE endurecido (Traefik desnudo expuesto → :80/:443 cerrados, firewall-crearack-stage) · OPS :80/:443 cerrados · 93.176.0.0/16 de casa acotado a solo-NetBird en los 5 firewalls · retirado firewall-staging-8000.