«¿Está abierto?» es la pregunta a la que todo el mundo recurre primero cuando una petición no llega, y es la pregunta equivocada, no porque esté mal formulada, sino porque presupone que hay una sola barrera. En una plataforma de infraestructura personal segmentada no hay una sola barrera. Hay al menos seis, apiladas, cada una respondiendo a una pregunta concreta que no tiene nada que ver con las demás, y cada una de ellas, sin excepción, tiene que responder «sí» antes de que una petición llegue de verdad a aquello a lo que intenta llegar.
He llegado a pensar en esto como una lista de comprobación fija, en lugar de una sensación vaga de «cosas de red». No porque estas seis concretas sean sagradas (una topología distinta podría tener cinco, u ocho), sino porque nombrarlas por separado es lo único que de forma fiable me ha sacado alguna vez del bucle de depuración en el que arreglas una cosa, el síntoma no cambia, y empiezas a dudar del arreglo en lugar de buscar la siguiente capa.
Las seis preguntas
1. ¿Existe siquiera un túnel o un peer de VPN? Antes que nada, ¿hay siquiera una relación entre quien llama y esta red (un peer de WireGuard configurado, un endpoint de túnel que conoce al otro lado)? Si la respuesta es no, todas las capas por encima de esta son irrelevantes, porque el paquete no tiene ninguna vía de entrada. Esta es la capa que la gente olvida que existe porque normalmente se configura una vez, funciona, y luego se queda sin tocar durante meses. Cuando se rompe en silencio (la configuración de un peer se desvía, una clave rota en un lado y no en el otro), todo lo que hay por encima también parece roto, y es tentador ir directo a «seguro que el firewall lo está bloqueando» sin comprobar siquiera si hay túnel. En esta plataforma, esa relación de peer tampoco es una VPN única e indiferenciada: el acceso privilegiado y el general circulan por túneles separados, así que «existe un peer» en realidad es «existe un peer en el túnel concreto que necesita esta petición».
2. ¿El enrutamiento lleva el paquete hasta ahí?
Que exista una relación de peer no significa que la red sepa cómo llevar una dirección de destino concreta a través de ella. Las tablas de rutas, estáticas o dinámicas, deciden qué interfaz y qué siguiente salto toma un paquete. Es perfectamente posible tener un túnel funcionando y una ruta hacia la subred equivocada, o ninguna ruta en absoluto hacia un segmento recién añadido: el túnel sube limpio, el ping al propio peer funciona, y el servicio en cuestión sigue siendo inaccesible porque nadie le dijo al router que su subred vive al otro lado de ese túnel.
3. ¿Una regla de firewall lo permite? Esta es la capa que la mayoría de la gente tiene en mente cuando dice «¿está abierto?», y es genuinamente importante, pero es solo una de seis. Una regla de firewall es una decisión estrecha de permitir/denegar sobre una combinación concreta de origen, destino, puerto y protocolo. Equivocarse con la regla (host correcto, puerto equivocado; puerto correcto, dirección equivocada; una regla que permite el segmento pero no el host concreto) produce exactamente el mismo síntoma que un problema de enrutamiento o un túnel ausente: la conexión, simplemente, no ocurre. Desde fuera, «sin ruta», «sin regla» y «sin túnel» son indistinguibles sin comprobar cada uno de ellos. Cada segmento aquí deniega por defecto exactamente en esta capa: nada cruza sin una regla explícita que lo nombre, lo cual es un trade-off real en sí mismo, detallado por separado.
4. ¿Resuelve el DNS el nombre siquiera? Esta capa está casi vergonzosamente separada de las tres primeras, y precisamente por eso causa confusión. Una ruta de red puede ser completamente correcta (túnel arriba, ruta presente, regla de firewall que permite el tráfico) y la petición sigue fallando porque el cliente, para empezar, nunca obtuvo una dirección IP a la que enviar el paquete. Los fallos de resolución DNS producen un error con un aspecto distinto al de una conexión bloqueada (normalmente un fallo rápido y limpio en lugar de un timeout), pero bajo presión, «esto no funciona» no distingue entre las dos cosas, y es fácil quemar tiempo revisando reglas de firewall para un host cuyo nombre nunca llegó a resolverse.
5. ¿La propia capa de auth de la aplicación acepta a quien llama? Ahora el paquete ha llegado de verdad, limpiamente, hasta el servicio. Aquí es donde el modelo mental de «accesibilidad» de mucha gente se detiene sin darse cuenta, pero no es el final: la aplicación todavía tiene voz propia e independiente. Una conexión válida, no bloqueada y correctamente enrutada puede seguir recibiendo un 401 o un 403, y ese fallo no tiene nada que ver con ninguna de las cuatro capas de debajo. Esta es también la capa que más se parece a «funcionando como estaba previsto» desde el punto de vista de la seguridad: que una petición llegue a la aplicación y sea rechazada por su propia auth suele ser el sistema haciendo exactamente lo que debe, no un bug que haya que rodear.
6. ¿El propio firewall local del host lo permite?
Por último, y fácil de olvidar precisamente porque a estas alturas todo lo demás ya parece estar bien: el host de destino puede tener su propio firewall local (iptables, nftables, un ufw a nivel de host, lo que sea que corra la plataforma de esa máquina en concreto) que es completamente independiente de la regla de firewall de perímetro o de segmento que resolvió la capa tres. Una regla que permite que un segmento llegue a un host no garantiza que el propio host esté configurado para aceptar la conexión en sus propias reglas, adyacentes al loopback. Esta capa responde a «esta máquina en concreto, por sus propios medios, ¿deja entrar esto?», y ninguna capa anterior habla en su nombre.
Recorrer la lista de comprobación de arriba abajo
El valor práctico del modelo solo aparece cuando de verdad se usa como una lista de comprobación ordenada y no como una lista de cosas que se conocen en abstracto. Supongamos que un servicio que ayer era accesible hoy no lo es, y nada del propio servicio ha cambiado. El instinto es empezar por donde parezca más probable: normalmente el firewall, porque las reglas de firewall son la capa a la que la gente está más predispuesta a echarle la culpa. Pero empezar por el medio significa que, si el problema real está una capa por debajo (enrutamiento) o una capa por encima (DNS), se va a gastar tiempo de verdad confirmando una capa que nunca estuvo rota, y lo que es peor, esa confirmación va a terminar con una falsa confianza: «he comprobado el firewall, está bien», lo cual descarta sutilmente lo que no era, sin hacer nada por confirmar lo que sí era.
Recorrer las seis capas en orden, de abajo arriba, convierte esa misma investigación en una secuencia de comprobaciones concretas y refutables: confirmar que el peer del túnel está de verdad levantado y que su handshake es reciente: no solo configurado, sino conectado de verdad ahora mismo. Confirmar que la tabla de rutas tiene una entrada que cubre el destino, y que apunta a la interfaz correcta. Confirmar que el conjunto de reglas de firewall todavía contiene la regla que se supone que debería tener, con el origen, destino y puerto correctos, y que no la está tapando una regla más amplia situada antes en el orden. Confirmar que el nombre de host usado resuelve de verdad, desde el mismo punto de vista del que parte la petición que falla, no desde una máquina de otro segmento donde el DNS se comporta de otra manera. Confirmar que los propios logs de la aplicación muestran la petición llegando y siendo rechazada, frente a no llegar en absoluto: esa distinción por sí sola dice si el problema está en las primeras cuatro capas o en las dos últimas. Y solo si todo eso queda despejado se mira el firewall local del propio host, porque en ese punto ya se ha confirmado que la petición debería estar llegando y algo local a la máquina se la sigue comiendo.
Cada una de esas seis comprobaciones es, por sí sola, genuinamente rápida. La disciplina no está en que ninguna comprobación individual sea difícil: está en resistir el impulso de parar en la primera capa que parezca plausible y declararla «probablemente el arreglo» antes de confirmar de verdad que el síntoma ha cambiado.
Por qué reducir esto a una sola pregunta rompe la depuración
Cada una de estas seis capas es, por sí sola, suficiente para producir exactamente el mismo síntoma visible para el usuario: la petición no se completa. Un timeout en la capa 1 se parece a un timeout en la capa 2, que se parece a un timeout en la capa 3. Un fallo de DNS en la capa 4 normalmente tiene un aspecto distinto (fallo rápido frente a quedarse colgado), pero bajo presión de tiempo esa distinción se pierde, y «esto no funciona» se convierte en todo el vocabulario diagnóstico disponible.
El peligro real no es que ninguna de estas capas sea difícil de comprobar: cada una, aislada, suele ser una comprobación de dos minutos. El peligro es la suposición implícita de que arreglar una de ellas debería arreglar el síntoma, y que, cuando no lo hace, se concluya que el arreglo estaba mal en lugar de concluir que hay otra capa, sin relación, que sigue fallando por debajo o por encima. He visto esto desarrollarse así: se corrige una regla de firewall, se confirma que es correcta con una herramienta de trazado de reglas, la petición sigue fallando, y el instinto es volver a dudar del arreglo del firewall, añadir otra regla, ampliarla, cuando el problema real era que el DNS nunca resolvió el nombre de host que se estaba usando, una capa que nunca se había tocado.
Tratar «¿está abierto?» como seis preguntas separadas y ordenadas, en lugar de una sola vaga, tiene un beneficio concreto y mecánico: convierte la depuración en una lista de comprobación que se recorre de arriba abajo (o de abajo arriba), en lugar de una única hipótesis en la que se cree o no se cree. ¿Existe el peer? Sí. ¿Lo lleva el enrutamiento? Sí. ¿La regla de firewall lo permite? Sí. ¿Resuelve el DNS? Ahí está, la cuarta pregunta, justo donde una suposición falsa («la ruta de red está bien, así que tiene que ser el DNS o la aplicación») la habría saltado directamente si el proceso se hubiera quedado en una sola pregunta colapsada en lugar de seis preguntas discretas.
Ninguna de las seis sustituye a ninguna otra, en ningún sentido. Una regla de firewall generosa no arregla un enrutamiento roto. Un registro DNS que funciona no implica que la aplicación vaya a aceptar a quien llama. Una regla de perímetro permisiva no invalida que el propio firewall local de un host descarte el paquete en el último salto. Cada capa responde siempre solo a su propia pregunta, y la petición solo llega a pasar cuando las seis, de forma independiente, dicen que sí.
El mismo modelo, leído como propiedad de seguridad en lugar de como ayuda a la depuración
Le das la vuelta al marco y las seis capas dejan de ser una lista de comprobación de depuración para convertirse, casi por accidente, en algo cercano a la defensa en profundidad. Como cada capa es genuinamente independiente (una regla de firewall de verdad no puede compensar una mala decisión de enrutamiento, y la auth de la aplicación de verdad no se puede saltar solo porque la ruta de red esté abierta), un error en una sola capa no se convierte automáticamente en una brecha. Configurar mal una regla de firewall, dejándola demasiado amplia, y la petición todavía tiene que superar el DNS, todavía tiene que superar la auth de la aplicación, todavía tiene que superar el firewall local del propio host, antes de llegar a ningún sitio. Eso no es tanto una redundancia diseñada a propósito como un efecto secundario de que las capas, genuinamente, no confían unas en otras para haber hecho su trabajo, que es exactamente la propiedad que la defensa en profundidad intenta lograr a propósito en otros sitios.
El corolario es que esto también corta en la otra dirección para el acceso legítimo: añadir un peer de túnel nuevo para un dispositivo nuevo no implica que ese dispositivo pueda de repente llegar a todo lo que hay en la red. Supera la capa uno. Todavía necesita una ruta, una regla de firewall, un nombre resoluble si se conecta por hostname, y todavía tiene que pasar lo que sea que exija la propia auth de la aplicación de destino. Cada capa nueva de fricción es también una capa nueva de contención, en ambas direcciones: para el intruso que intenta llegar más lejos de lo que debería permitir una única configuración errónea, y para el cambio bienintencionado que no debería conceder más acceso del que pretende. Razonar sobre las seis capas de forma explícita, en lugar de tratar la «accesibilidad» como una propiedad difusa que un sistema tiene o no tiene, es lo que hace posible añadir o retirar acceso en exactamente una capa con confianza sobre qué afecta ese cambio y qué no afecta en ningún otro sitio.
La red de gestión es la versión más afilada de este modelo: véase Aislar el plano de gestión para lo que ocurre cuando una de estas seis capas es un límite pensado para no cruzarse jamás, por diseño, en lugar de ser simplemente estrecho.