Defina la operación de VPN antes de comparar API
El control de conexiones, el aprovisionamiento de perfiles, la administración de usuarios y la observación son API distintas. Nombre primero el objeto, la acción y la condición de éxito.
Una página de producto dice que tiene una API, y la reunión de integración se atasca en la segunda pregunta. ¿Qué operación, sobre qué objeto, invocada por quién y qué cuenta como éxito? Responder esas cuatro antes de comparar productos suele eliminar a la mitad de los candidatos. También convierte la comparación restante en algo que una prueba puede resolver.
Sustituya la afirmación de que tiene una API por una sola operación
Una API es un transporte, no una capacidad. Un punto de conexión REST, un socket local y un envoltorio de línea de comandos pueden llamarse API, y no ofrecen operaciones equivalentes.
Escriba la operación como una frase antes de mirar la documentación.
Iniciar una conexión local es una acción del lado del cliente con un usuario delante. Emitir un perfil de dispositivo es una acción de aprovisionamiento con un inventario detrás. Desactivar el acceso de un usuario es una acción administrativa con un rastro de auditoría. Esas tres suelen vivir en componentes distintos, propiedad de equipos distintos, con autoridad distinta.
Cuatro campos que hacen comprobable el contrato
Rellene cuatro campos para cada operación: el objeto, la acción, el invocador y la condición de éxito. Un contrato al que le falta un campo es un deseo.
La tabla es toda la hoja de trabajo:
| Field | Question | Example |
|---|---|---|
| Object | What is being acted on? | One enrolled device |
| Action | Observe, create, change, start, stop, or revoke? | Revoke |
| Caller | Which identity calls it? | Deployment service |
| Success | What observable state proves it? | Future sign-in denied |
La condición de éxito es el campo que la gente omite, y es el que decide si la integración funciona. Un ajuste guardado no es un túnel activo, y una cuenta deshabilitada no es una sesión terminada.
Si dos operaciones necesitan invocadores distintos, son dos integraciones. Agruparlas en una sola cuenta de servicio suele significar conceder más autoridad de la que necesita cualquiera de las dos.
Ajuste la interfaz a su capa real
La interfaz de gestión comunitaria de OpenVPN habla con un demonio por TCP o por un socket Unix. Sus órdenes incluyen observaciones de estado y señales al demonio.
Eso la convierte en un canal de control del demonio, no en una API de suscripción alojada ni en un servicio de alta de usuarios. Leer su documentación con cuidado evita construir contra una capa que no posee el objeto.
Esa documentación también dice que el protocolo no lleva cifrado propio. Quien pueda alcanzar el socket puede controlar el demonio, así que trátelo como control sensible y no como un flujo de métricas. Átelo a loopback o a un socket Unix, y póngalo detrás de un arreglo restringido si un invocador remoto lo necesita. Exponerlo a internet por comodidad convierte un canal de control en un incidente.
Especifique el comportamiento tras la llamada
La aceptación no es lo mismo que la finalización. El demonio puede volver antes de que el túnel esté levantado, así que espere el evento documentado de finalización o de fallo y vincúlelo a la petición que envió.
Decida qué hace el invocador si se pierde la respuesta. Repetir una creación o una reconexión a ciegas no es lo mismo que comprobar si la primera petición ya surtió efecto.
Retirar el acceso son al menos tres acciones distintas: bloquear el inicio de sesión futuro, terminar una sesión viva y revocar la credencial. Pida las que la política realmente exige, y diga en el contrato cuál es cuál. No etiquete una actualización de cuenta exitosa como revocación completa sin pruebas. La diferencia importa durante un incidente, cuando el reloj corre.
Compruebe el contrato con un piloto
Un piloto pequeño y aprobado debería cubrir éxito, rechazo, interrupción y reintento, seguido de la operación de aplicación que se supone permitida o denegada.
Para una interfaz a nivel de demonio, dos órdenes ejercitan la observación y una señal:
echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505Conceda solo la autoridad que la operación requiere. Mantenga los secretos fuera de los registros rutinarios y registre suficiente detalle privado para decir qué objetivo se vio afectado y cómo terminó.
Escriba la ruta de recuperación para el caso de que la propia API de control esté caída. Elija la interfaz que posee el objeto y su ciclo de vida; las afirmaciones de automatización en una página de producto no son un sustituto.