Escriba un informe de diseño de VPN que alguien pueda revisar de verdad

La mayoría de las revisiones de diseño se atascan en la primera pregunta, porque la solicitud describe un producto y no una decisión. Un informe que nombra los flujos, los responsables y el comportamiento ante fallos se puede responder en una reunión. Un informe que dice construyan una VPN segura no se puede responder en absoluto. Recorra las seis comprobaciones siguientes antes de enviar nada, y la revisión se convierte en una comparación en lugar de un debate.

Primero, ¿la pregunta es una decisión o un deseo

Una decisión tiene alternativas y una observación que elegiría entre ellas. Si no puede nombrar qué miraría para elegir una, la pregunta sigue siendo un deseo. Escriba primero las alternativas, aunque la lista solo tenga dos elementos. Después escriba el compromiso que las separa.

Un deseo también tiende a ocultar al público. Diga quién debe aprobar el diseño, porque el mismo informe se lee de forma distinta para un responsable de red, un revisor de seguridad y un aprobador financiero.

Deténgase aquí si la respuesta es nadie, porque una decisión sin propietario será rehecha por quien se queje más alto. Eso es un problema de gobernanza y no un problema de diseño.

Segundo, nombre los flujos y las denegaciones

Enumere el origen, el destino y la aplicación de cada flujo que debe funcionar. Después enumere los flujos que deben seguir fallando, porque un diseño que los permite en silencio ha cambiado el requisito sin decirlo. El solapamiento de direcciones y el alcance aguas arriba pertenecen a esta lista como restricciones y no como sorpresas.

Sea concreto sobre la dirección. Una sede que puede iniciar conexiones hacia la central es un diseño distinto de una que puede aceptarlas, y la diferencia aparece en cada regla que escriba después.

Anote también los clientes y su estado de gestión, porque un dispositivo gestionado con un agente puede hacer cosas que un portátil traído por el usuario no puede.

Mantenga la lista lo bastante corta para probarla. Diez flujos que puede verificar valen más que cuarenta que no puede.

Comprobación 3: separe los hechos de las suposiciones

Marque cada afirmación que haya verificado y marque las que no. El direccionamiento público, el caudal disponible y el acceso de administrador son las tres suposiciones que más a menudo cambian la respuesta. Si una de ellas es desconocida, diga cómo cambia el diseño cuando resulte en cualquiera de los dos sentidos.

Una red ilustrativa está bien siempre que esté etiquetada. El problema es una sucursal hipotética que adquiere en silencio un segundo enlace ascendente o un bloque de direcciones públicas que nunca tuvo.

Verifique la suposición que pueda comprobar antes de la revisión, porque un solo hecho medido elimina una rama entera de discusión.

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

Cuarto, escriba el contrato de fallo

Diga qué ocurre cuando el túnel está caído y sea explícito sobre las dos promesas distintas. Restaurar conexiones nuevas tras una reconexión es fácil de prometer. Preservar las sesiones que ya estaban establecidas durante un fallo es un requisito mucho más fuerte, y limita la elección de tecnología.

Luego decida el plan alternativo: bloquear el tráfico, encaminarlo por otra vía aprobada o hacer algo distinto por aplicación. Una vuelta silenciosa a un camino directo es una decisión de diseño aunque nadie la haya escrito.

Añada el objetivo de recuperación en lenguaje llano, como cuánto tiempo puede operar una sede en estado degradado y quién declara el incidente.

Comprobación 5 y 6: elija la costura y registre el cambio

Elija una costura para discutir, porque una revisión que intenta resolverlo todo no resuelve nada. El enrutamiento, la autorización y el cifrado son tres costuras distintas, y el informe debe decir de cuál va la pregunta. RFC 4301 es un recordatorio útil aquí, porque separa las decisiones de política, el tráfico protegido y las asociaciones de seguridad en lugar de tratarlas como un solo objeto.

Después registre qué cambió tras la decisión, incluidas las suposiciones revisadas. Ese registro es lo que hace más corta la siguiente revisión.

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

Un informe que supera las seis comprobaciones produce una pregunta con respuesta: el diseño cumple los flujos declarados y el contrato de fallo, o una restricción nombrada lo impide. Cuando la restricción cambie más adelante, el registro muestra qué decisión hay que revisar y cuál puede mantenerse. Eso hace que el ejercicio sea reutilizable y no un debate puntual.