Inventario de VPN: acceso previsto, configuración generada y sesiones activas
El nombre de un túnel es una observación, no un registro de servicio. Una al inquilino, la configuración desplegada y la evidencia de contabilidad antes de retirar algo.
Todo nombre de túnel parece una fila de inventario hasta que uno pregunta a quién pertenece. Un nombre le dice que algo está conectado ahora mismo; no puede decirle a quién pertenece el servicio, qué se les permite alcanzar ni si la configuración que produjo el túnel es la que usted aprobó. A escala de flota, esas tres preguntas son el inventario, y el túnel es solo la observación más reciente.
Un servicio, tres registros
El servicio previsto es aquello a lo que el inquilino tiene derecho: identidades, prefijos, recursos y un estado de ciclo de vida. La configuración desplegada es la política generada que debería hacerlo realidad. La sesión observada es evidencia de tiempo de ejecución de que algo se conectó. Tratarlos como una sola tabla funde tres tipos distintos de verdad en una fila que está mal de tres maneras a la vez.
| Record | Answers | Goes stale when |
|---|---|---|
| Intended service | Who may reach what | A contract changes and nobody edits the record |
| Deployed configuration | What the gateway was told | A device is edited by hand |
| Observed session | What is running now | Telemetry stops or a session ends |
La prueba práctica es una pregunta que cada registro puede responder solo. Pregunte quién posee este prefijo y responde el registro del servicio previsto. Pregunte qué política mantiene la puerta de enlace y responde el registro desplegado. Pregunte si alguien lo usó esta semana y responde el registro de sesión. La columna que no puede responder su propia pregunta es la que hay que arreglar primero.
Registre al inquilino, no la interfaz
Dé a cada servicio un identificador que sobreviva a una reconexión. Una interfaz de túnel temporal o un número de sesión cambian por razones que no tienen nada que ver con el cliente, y un inventario basado en uno de ellos crece una fila nueva cada vez que un enlace parpadea. Básalo en el inquilino y el servicio, y después ate las observaciones a esa clave.
El registro necesita al inquilino y al operador responsables, la identidad de par o de usuario aceptada, una referencia a la credencial en lugar de una copia, los prefijos protegidos, el contexto de enrutamiento, los recursos permitidos y el estado de ciclo de vida previsto. El material de credenciales pertenece al almacén de secretos admitido; un inventario que lleva claves privadas se ha convertido en una segunda copia del entorno, peor protegida.
La configuración generada tiene dueño y versión
La automatización lo hace más fácil y lo esconde mejor. Un generador que se ejecuta con éxito demuestra que la plantilla se renderizó, no que cada dispositivo coincida con la salida. Alguien acabará cambiando una puerta de enlace a mano durante un incidente, y ese cambio es lo más valioso que se puede capturar, porque es el único que ninguna ejecución posterior reproducirá.
Registre qué revisión produjo la política desplegada, y conserve las ediciones directas como una diferencia que hay que conciliar en lugar de sobrescribirlas en silencio. La conciliación es el producto aquí: el éxito del generador y el estado real del dispositivo son dos hechos que hay que comparar, no dar por iguales.
Las sesiones son evidencia, no autorización
Donde el despliegue usa contabilidad RADIUS, el RFC 2866 ofrece campos concretos con los que trabajar. Acct-Status-Type distingue un inicio de una parada, y los registros de una misma sesión comparten un Acct-Session-Id. Esos campos permiten reconstruir cuándo empezó y terminó una sesión sin confiar en el resumen de un panel.
Un identificador de contabilidad es evidencia de tiempo de ejecución. No define qué inquilino posee una subred y no concede acceso a nada. Correlaciónelo con la puerta de enlace y la identidad del servicio, y después guarde el momento de recolección junto a la observación. Un informe ausente puede ser un fallo de telemetría y no una ausencia de uso, y un registro antiguo no es prueba de que el acceso siga activo ahora.
La retirada usa la misma unión
Quitar un servicio significa quitar el acceso previsto, las credenciales y las sesiones activas, en ese orden, a través de los dueños de cada uno. Luego verifique que la configuración obsoleta ya no está en los dispositivos y que sus rutas permitidas ya no se resuelven. Un cliente que se fue el trimestre pasado no debería seguir apareciendo en una lista de prefijos porque se borró el nombre del túnel pero no la ruta.
Nada de esto exige un dispositivo por función ni un producto de automatización concreto. El requisito operativo es más estrecho y más difícil: un cliente, su acceso previsto, la política desplegada y la evidencia actual de tiempo de ejecución deben poder unirse sin depender de la memoria de alguien sobre un nombre de túnel. Construya primero los tres registros y luego elija las herramientas que los mantienen.