# ArquitecturaLos patrones que hacen funcionar al firewall: HA, zonas, seguridad transparente, inspección SSL. ## Vista general ``` ┌──────────────────────────────┐ ISP A ──────────────┤ │ │ Sovereign Edge Firewall ├── Zona: Clientes ISP B ──────────────┤ (activo / pasivo failover) │── Zona: VPN │ │── Zona: Anonimización │ • Filtro stateful │── Zona: Privacy │ • NAT (por uplink) │── Zona: DMZ │ • Offloading SSL transparente│ │ • Monitor de failover │ └──────────────────────────────┘ ``` El firewall se sitúa en el edge de la red con dos uplinks paralelos a internet. Internamente presenta una interfaz lógica hacia cada zona aislada. ## Alta disponibilidad dual-provider Dos uplinks (p. ej. fibra + LTE/5G o dos operadoras) se conectan en paralelo. Un monitor de failover vigila el estado del enlace, la alcanzabilidad del gateway y la latencia, y conmuta la ruta por defecto al uplink secundario en **menos de cinco segundos** ante un fallo. Propiedades clave: - **Ruleset simétrico.** Ambos uplinks comparten reglas de filtro, NAT y scrub. No hay un "camino bueno" y otro "malo". - **NAT dinámico.** El source NAT toma la IP de egress de la interfaz activa dinámicamente — sin IPs codificadas en duro, sin mapeos obsoletos en el failover. - **Override selectivo.** Clases concretas de tráfico pueden fijarse al uplink secundario (p. ej. un camino proxy anonimizador, balanceo de carga para servicios intensivos en descarga). - **Failback automático.** En cuanto el primario está sano de nuevo, el monitor revierte la ruta por defecto automáticamente. - **Pruebas de failover.** Un drill definido (ver [Operación](../operations/)) verifica trimestralmente que el failover funciona — no solo en teoría. ## Segmentación por zonas En lugar de una topología plana "dentro/fuera", el firewall opera sobre un modelo multi-zona. El movimiento lateral entre zonas está bloqueado por defecto. | Zona | Propósito | Perfil egress | |---|---|---| | Clientes | Puestos de trabajo de empleados | Proxy HTTP/HTTPS transparente con inspección de contenido | | VPN | Acceso remoto y túneles site-to-site | Perfil egress por túnel | | Anonimización | Cargas sensibles (investigación, denunciantes) | Todo el tráfico vía Tor, incluido DNS | | Privacy | Cargas de protección máxima | Anonimización + capa extra | | DMZ | Servicios accesibles desde el exterior | Reverse proxy endurecido delante de los servicios | Cada zona tiene su propio: - **Ruleset de filtrado** — qué entra, qué sale. - **Política NAT** — qué IP de egress, qué uplink preferido. - **Capa de inspección** — si HTTPS se intercepta, qué se loguea. - **Tablas whitelist/blocklist** — alimentadas desde las salidas de los daemons (ver docs [Abusive HTTP Watch](../../abusive-http-watch/)). ## Capas de seguridad transparentes Los endpoints en la zona de clientes reciben las siguientes protecciones sin configuración local: ### Offloading SSL como antivirus La capa más valiosa desde el punto de vista operativo. El razonamiento: - Más del 90 % de las amenazas web modernas — descargas de malware, payloads de phishing, exploits drive-by — se entregan sobre TLS. - El antivirus endpoint (Defender, Bitdefender, …) corriendo en el puesto solo ve el flujo cifrado. Solo puede detectar el fichero infectado **después** de que el dispositivo lo haya desempaquetado. - En ese punto, el dispositivo ya ha ejecutado las primeras etapas de la payload. La contención se convierte en respuesta a incidente. El firewall en cambio termina TLS en el gateway, entrega el texto plano a un motor antivirus, y solo entonces reenvía el contenido al endpoint. El endpoint ve un flujo ya escaneado. El malware se bloquea **antes de llegar al dispositivo**. La CA usada para el bump es la [Sovereign Certificate Authority](../../sovereign-certificate-authority/) — los clientes confían en los certificados del gateway porque la raíz de la CA interna está instalada vía gestión de configuración estándar. ### Filtro de contenido Redes publicitarias, dominios de trackers y hosts conocidos como maliciosos se filtran antes de entregarse. Reduce el peso de las páginas, elimina una clase de ataques supply-chain (JavaScript de red publicitaria comprometido) y mejora la privacidad. ### Tor / pasarela de anonimización La zona de anonimización **no tiene egress directo a internet en absoluto**. Todo el tráfico TCP se enruta de forma transparente por un daemon Tor local, incluyendo consultas DNS (vía un resolver local que usa el puerto DNS de Tor). Los endpoints en esta zona no necesitan cliente Tor local — la red fuerza el enrutamiento. ### I2P / pasarela privacy La misma idea que la zona Tor, una capa más profunda. Usado para cargas donde la confianza en los nodos de salida Tor también es una preocupación. ## Defaults operativos - **Default-deny.** Cada regla que permite tráfico es explícita. Protección anti-spoofing, validación de ruta inversa y heurísticas anti-scan corren por defecto. - **Límites de estado de conexión.** Cientos de miles de sesiones paralelas soportadas; los topes por origen previenen el agotamiento de la tabla de estado. - **Normalización del tráfico.** Reensamblado TCP, MSS clamping y protección anti-fingerprinting aplicados a todos los caminos de egress — importante para uplinks móviles y túneles VPN. - **Dual stack.** IPv4 e IPv6 son first-class, incluyendo la mecánica moderna de ICMPv6 (Router Advertisement, Neighbour Discovery). ## Dónde encaja el daemon El daemon compañero [Abusive HTTP Watch](../../abusive-http-watch/) escribe una blocklist que el firewall consume vía un cron de recarga de tabla. Eso añade una capa de bloqueo conductual sobre las reglas estáticas — IPs que probablemente prueban exploits se descartan en el edge. ## Lo que esto no es - No es una caja vendor que se compre. Es un patrón de entrega, no un SKU de producto. - No es un proyecto para principiantes. Operar esto responsablemente requiere operadores competentes (o el servicio [Operación](/es/services/support/) para proporcionarlos). - No es "configurar y olvidarse". Los conjuntos de tokens, blocklists y reglas de zonas requieren mantenimiento — ver [Operación](../operations/).