El diseño más simple posible para el acceso remoto a un montaje self-hosted pequeño es un solo túnel: todo el mundo y todo lo que necesita entrar recibe un peer en la misma VPN, y cualquier control de acceso que importe ocurre después, en la capa de aplicación o de firewall. Son menos piezas móviles, una sola configuración sobre la que razonar, una sola interfaz que levantar. Durante un tiempo, esa simplicidad parece el trade-off correcto.
Deja de parecerlo en el momento en que se piensa bien qué es lo que un único túnel compartido acopla en realidad: el radio de impacto de cada decisión de acceso se convierte en el mismo radio de impacto para todas. Revocar un peer significa revocar el nivel de acceso que tuviera ese peer, pero si «el nivel de acceso que sea» abarca desde paneles de solo lectura hasta root en la máquina que hace funcionar todo lo demás, entonces cada decisión de revocación es también, se quiera o no, una decisión sobre lo más privilegiado que hay en esa red. No hay forma de reducir el acceso general del día a día sin que la misma palanca toque también el acceso de administración, porque es la misma palanca.
Dos túneles, dos radios de impacto
La solución no es una capa de control de acceso más sofisticada añadida a una sola VPN: es, para empezar, no hacer pasar el tráfico privilegiado y el general por la misma tubería. El acceso de administración privilegiado y el acceso general circulan por dos túneles completamente separados. Conjuntos de peers distintos, claves distintas, interfaces distintas y, de forma crítica, ningún archivo de configuración compartido en el que tocar uno afecte por accidente al otro. Los dos túneles no necesitan saber nada el uno del otro. El lugar donde esta separación se aplica con más consecuencias es el propio plano de gestión, donde el segundo túnel no sirve solo para limitar el radio de impacto entre dos niveles de acceso de usuario: es la única ruta hacia la capa capaz de reiniciar el hipervisor que hay debajo de todo lo demás.
El beneficio se nota específicamente en el momento de la revocación, que es el momento en que los diseños de control de acceso se ponen realmente a prueba. Si un dispositivo de acceso general se pierde o se ve comprometido, sacarlo de la lista de peers del túnel general es un cambio acotado por completo a ese túnel. No puede, por construcción, tocar la lista de peers del túnel de administración, porque es un archivo distinto, una interfaz distinta, un conjunto de claves distinto. No hay que preguntarse si quitar un peer de un túnel tiene algún efecto secundario en el otro: no existe estado compartido por el que un efecto secundario pueda viajar. El aislamiento no es una política que haya que acordarse de aplicar; es una propiedad de la topología.
Esto importa más específicamente para un montaje al estilo WireGuard que para algunos diseños de VPN, porque WireGuard no ofrece de serie una noción de «rebajar el privilegio de esta sesión» ni una lista de revocación central que se consulte al conectar. Un peer está configurado en una interfaz o no lo está: el acceso se concede y se retira editando la configuración de peers, no mediante una comprobación de autorización en tiempo de ejecución que revoque de forma centralizada un token de sesión. Eso es una parte deliberada del diseño del protocolo: en lugar de cadenas de certificados y CRL, cada peer es simplemente una entrada de clave pública, y retirar el acceso significa retirar esa entrada. Es un mecanismo genuinamente simple, pero los mecanismos simples no componen seguridad por sí solos: simplemente hacen exactamente lo que se les ha configurado, lo que significa que el límite de la seguridad tiene que estar, en la práctica, en el propio límite de configuración. Si se ponen peers privilegiados y generales en la configuración de la misma interfaz, el mecanismo dejará encantado que un cambio de acceso general roce el acceso de administración, porque, en lo que a WireGuard respecta, solo hay un túnel y una lista de peers que editar.
Por qué el peer es un dispositivo, no una persona
La segunda pieza se deriva de la misma lógica llevada un nivel más abajo. En este montaje, la identidad de un peer es por dispositivo, no por persona. El portátil de Alberto es un peer. El móvil de Alberto es otro peer distinto. Si una misma persona usa el acceso legítimamente desde tres dispositivos distintos, eso son tres entradas de peer separadas, tres claves separadas, no una única identidad compartida multiplexada entre los tres.
Esto parece más papeleo que un modelo por persona, y lo es, marginalmente. Lo que compra a cambio es precisión justo en el momento en que la precisión importa: un dispositivo perdido o comprometido se revoca como lo que es, sin tocar ningún otro dispositivo que esa misma persona posea. Si en cambio la identidad fuera por persona, perder un dispositivo obligaría a elegir entre dejar abierto un hueco de seguridad (un dispositivo robado con credenciales válidas a nivel de persona todavía en la red) o revocar por completo el acceso de esa persona y tumbar de paso sus otros dispositivos, no comprometidos. Ninguna de las dos opciones es buena, y la identidad por dispositivo es lo que elimina la necesidad de elegir entre ellas. Es el mismo principio que la separación en dos túneles, aplicado a la unidad de confianza más pequeña que tiene el sistema: no dejar que una sola credencial abarque más superficie de riesgo que aquello para lo que realmente está pensada.
Esto sí significa que la rotación de claves y el aprovisionamiento de dispositivos son tareas recurrentes y continuas, no una configuración de una sola vez: cada dispositivo nuevo es un par de claves nuevo y una entrada de peer nueva, y perder un dispositivo significa una rotación específicamente para esa entrada. Es una sobrecarga real. Es una sobrecarga que escala con el número de dispositivos, no con el número de personas, lo cual en un montaje personal pequeño la mantiene acotada, y es una sobrecarga que se paga en el momento de añadir o perder un dispositivo, que es un evento raro y deliberado, en lugar de una sobrecarga que se paga de forma continua como sí ocurriría con la exposición al riesgo constante de un diseño de túnel compartido.
El lado del coste en la balanza
Vale la pena ser honesto sobre lo que cuestan de verdad dos túneles, porque el diseño solo tiene sentido si ese coste es menor que el riesgo que elimina. Cada dispositivo que necesita los dos niveles de acceso (que en un montaje de una sola persona suele ser solo la máquina principal del propio operador) necesita dos interfaces levantadas, dos juegos de claves gestionados, dos configuraciones mantenidas en orden. Eso no es gratis. Tampoco es la sobrecarga que podría parecer: levantar una segunda interfaz WireGuard es un archivo de configuración y un up/down, no una segunda pieza de infraestructura que mantener en marcha. El coste operativo se parece más a «una cosa más que recordar que existe» que a «un sistema más que mantener».
El coste más interesante es conceptual, no mecánico: con dos túneles no hay un único sitio que responda a «qué puede alcanzar este dispositivo ahora mismo». Hay que comprobar en qué túneles es peer un dispositivo para conocer su alcance real, en lugar de leer una sola configuración y saberlo todo. Para un número pequeño de dispositivos, eso es una lista mental corta. Deja de ser una lista mental corta si el número de dispositivos crece mucho, momento en el que el modelo de dos túneles querría algún tipo de inventario (una tabla sencilla de dispositivo, túnel, propósito) en lugar de apoyarse en la memoria como puede hacerse a pequeña escala. Ese es un límite real de hasta dónde escala este diseño tal cual está, y merece señalarse con honestidad en lugar de fingir que la separación en dos túneles es, por sí sola, un sistema completo de control de acceso.
Por qué no un solo túnel con mejor segmentación interna
Una objeción razonable aquí es que WireGuard soporta AllowedIPs por peer, así que se podría usar un solo túnel y restringir hacia dónde puede enrutar cada peer, segmentando en la práctica el privilegio dentro de una única interfaz en lugar de separarlo en dos. Es una opción real, y para algunos montajes es la correcta. La razón por la que no fue la elegida aquí tiene que ver con qué pinta tiene un error bajo cada modelo. Con restricciones de enrutamiento por peer dentro de un solo túnel, una entrada AllowedIPs mal configurada, un error de copiar y pegar al añadir un peer nuevo, o un fallo en la gestión de la configuración puede conceder en silencio a un peer de acceso general una ruta hacia territorio privilegiado, y el fallo es invisible hasta que alguien nota tráfico que no debería ser posible. Con dos túneles físicamente separados, el error equivalente exigiría poner la clave de un peer directamente en la configuración del túnel equivocado, lo cual es un error mucho más ruidoso y visible: o bien el peer no tiene ninguna forma de llegar al lado privilegiado, o bien un administrador que mira la lista de peers del túnel de administración ve una entrada que claramente no pinta ahí. Separar por túnel convierte un fallo de enrutamiento sutil en un error de archivo obvio, lo cual es una forma de fallo mejor aunque cueste una interfaz extra que mantener.
Lo que esto no arregla por sí solo
Nada de esto sustituye a lo que pasa después del túnel: que un peer esté en el túnel de administración es necesario para el acceso privilegiado, no suficiente. Lo que autentique y autorice las acciones una vez que el tráfico está dentro sigue teniendo que sostenerse por sí mismo; la separación de túneles reduce quién puede siquiera intentar acciones privilegiadas, no sustituye a los controles propios de esa capa. Y el diseño es tan bueno como lo sea la higiene de claves en cada dispositivo: la simplicidad de WireGuard significa que no hay ninguna autoridad central rotando cosas por ti en silencio si una clave privada lleva mucho tiempo sin rotarse, así que la disciplina de retirar y rotar peers de verdad cuando un dispositivo cambia de manos o desaparece sigue siendo un hábito manual que mantener, no algo que la topología imponga de forma automática.
También hay un coste de papeleo fácil de infravalorar hasta que se vive de verdad: dos túneles y peers por dispositivo juntos significan que la fuente real de verdad de «quién puede llegar a qué» son dos listas de peers separadas, cada una creciendo una entrada por dispositivo en lugar de una entrada por persona. Es una sobrecarga pequeña y deliberada para un único operador con un puñado de dispositivos. Es la parte de este diseño con más probabilidades de necesitar un inventario de verdad (qué clave pertenece a qué dispositivo físico, añadida en qué fecha, rotada por última vez cuándo) en cuanto el número de dispositivos supere lo que cabe cómodamente en la memoria. Construir ese inventario antes de que haga falta sería prematuro; no construirlo una vez que las listas de peers sean lo bastante largas como para perderles la pista a simple vista sería, en sí mismo, un modo de fallo silencioso, solo que más lento que el de un túnel compartido.
Esta separación de túneles es una pieza de un modelo de accesibilidad más amplio, no todo el modelo: véase Seis capas de accesibilidad para ver cómo «existe un peer» encaja junto al enrutamiento, las reglas de firewall, el DNS y la autenticación de la aplicación como una de seis cosas independientes que tienen que decir todas que sí antes de que una petición llegue a ninguna parte.