Fail-open o fail-closed: qué decide un kill switch de VPN
Ambos términos describen qué ocurre cuando el túnel ya no está, no cuán fuerte es el cifrado. El alcance que elijas decide si el tráfico realmente se filtra.
El mito es que fail-closed es la configuración segura y fail-open la descuidada. Ambos describen qué ocurre con el tráfico una vez que el túnel desaparece, y ninguno cambia lo bien que cifra ese túnel. Una política fail-closed con una lista amplia de excepciones puede filtrar más que una política fail-open en un dispositivo que nunca sale de la red de la oficina. Elige el resultado que puedas explicar a la persona que es dueña del tráfico.
La etiqueta describe un resultado, no una fortaleza
El vocabulario viene de los sistemas de control: fail-open permite la operación cuando un componente falla, fail-closed la niega. Aplicado a una VPN, el componente que falla es el túnel, y la pregunta es si se permite que el tráfico continúe por otra ruta. La elección del cifrado, la longitud de la clave y el protocolo son decisiones separadas.
La confusión persiste porque un kill switch suena a función de seguridad, y los proveedores lo venden como tal. Mecánicamente es una regla de enrutamiento y cortafuegos que bloquea el tráfico que el túnel debía llevar, implementada en el cliente, en el sistema operativo o en la pasarela. La capa que la aplica también define su cobertura, y una regla en una capa no cubre otra. Una regla en la pasarela no puede proteger un portátil que ya se ha movido a otra red.
Cómo se ve cada resultado
La misma política puede comportarse de forma muy distinta según el fallo con el que te encuentres, así que compara los eventos en lugar de las etiquetas.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
La última fila es la que atrapa a quienes suponen que un kill switch es un solo interruptor. Una regla escrita para la tabla de rutas IPv4 deja intacta la ruta predeterminada IPv6, y la aplicación puede usarla tan tranquila.
El alcance decide si hay fuga
Pregunta qué cubre la política antes de preguntar qué modo es. Una regla por aplicación protege una app y nada más, una regla para todo el dispositivo protege todo salvo las excepciones, y una regla en la pasarela solo protege el tráfico que llega a esa pasarela. El DNS necesita su propia decisión, porque una consulta enviada a un resolutor local puede revelar nombres incluso cuando la carga útil está bloqueada.
Las excepciones de red local existen para impresoras, transmisión de pantalla y portales cautivos, y cada una es un agujero en el bloqueo. Documéntalas junto a la política, porque quien herede la configuración leerá fail-closed como absoluto si no.
Reconectar y bloquear también son controles separados. Un cliente puede reconectarse automáticamente sin bloquear nunca, o bloquear sin reconectarse, y la combinación determina qué experimenta un usuario durante una interrupción.
Demuéstralo durante una transición
Probar el estado estable no demuestra nada. Tira el túnel a propósito y prueba la aplicación que debería estar protegida, y luego comprueba si llegó a la red. Compara el indicador del cliente con el resultado, porque un indicador que sigue diciendo conectado es justo el caso para el que existe la política. Si la aplicación protegida lo consigue, el nombre del modo da igual; tienes una fuga.
Repítelo desde un arranque en frío antes de iniciar sesión, en un cambio de Wi-Fi a red móvil y con la app protegida en segundo plano. Si el bloqueo lo aplica el proceso del cliente, prueba también qué ocurre cuando ese proceso se mata en lugar de cerrarse limpiamente.
Por último, revisa la ruta de limpieza. Si se desinstala un cliente mientras sus reglas están activas, usa el procedimiento de eliminación documentado por el proveedor en lugar de desactivar el cortafuegos del sistema operativo, que retira protección no relacionada sin responder a quién pertenece la regla sobrante.