Escribe la ruta del paquete antes de configurar la VPN

La mayoría de las instalaciones de VPN empiezan con un cliente y un perfil, y para cuando el túnel está levantado nadie sabe qué paquete debía atravesarlo. La primera página de trabajo es más barata que la tercera hora de depuración: describe una conexión prevista de extremo a extremo, en papel, antes de que exista un archivo de configuración. El ejercicio suele resolver una pregunta que aún no habías hecho, como si el requisito es una salida a internet, un acceso remoto a una subred o un enlace entre dos sedes.

Una conexión basta para empezar. Tres páginas de topología suelen esconder la misma respuesta que falta.

Describe una solicitud, no un diagrama

Empieza por el emisor: un rango de direcciones, una familia de direcciones y la aplicación que origina el tráfico. Después nombra el prefijo de destino y el servicio que hay en él, hasta el puerto y el protocolo, porque una regla que permite la subred pero no el servicio es una regla que no hace nada. Las dos direcciones son todo el asunto, y todo lo que sigue es la maquinaria que debe concordar con ellas.

Enumera la ruta en orden: el enlace físico, el extremo de la VPN en cada lado, el túnel mismo y la red que hay más allá. Escribe los nombres de las interfaces si los conoces, porque ese detalle es lo que convierte una descripción en algo que puedes comparar después con una tabla de enrutamiento. Añade la dirección que usa cada interfaz en el lado del túnel. Sin esos dos datos, nadie más puede comprobar el registro contra el dispositivo.

Ahora nombra la única conexión prevista en una sola frase en la parte superior de la página. Si esa frase necesita la palabra o, tienes dos diseños y deberías tratarlos por separado.

Sigue la respuesta antes que la solicitud

Una ruta que solo describe la dirección de salida es medio documento. Sigue la respuesta de vuelta e identifica qué dispositivo conoce el rango del emisor, si una traducción cambia el origen de salida y dónde se espera que entre el paquete de retorno. La respuesta es donde fallan la mayoría de las instalaciones, porque la solicitud es fácil de observar y la respuesta no.

Anota explícitamente cualquier traducción de direcciones, incluido dónde ocurre y qué ve entonces el extremo remoto. Un par que registra una dirección y enruta hacia otra está describiendo dos diseños distintos.

Trata la resolución de nombres como su propio intercambio y no como parte de la ruta de la aplicación. Un registro interno puede necesitar un resolutor al que solo se llega por el túnel, y un registro de ruta que termina en el prefijo de la aplicación no lo revelará. Lo mismo vale para cualquier validación de certificados que dependa de alcanzar una autoridad interna.

Da un responsable a cada decisión

Para cada ruta, regla de cortafuegos, selector y credencial, anota qué configuración la contiene y qué persona puede cambiarla. Un responsable por línea es lo que hace que el documento sobreviva a la primera solicitud de cambio, porque la alternativa es un documento que describe la intención y una red que describe la historia.

Ojo con dos responsables de un mismo valor por defecto. Un script de cliente y un gestor de red pueden instalar rutas sin que ninguno sepa del otro, y un permiso de escucha en la pasarela no es el mismo permiso que el reenvío. Ambos casos producen un registro de ruta correcto en papel y equivocado en el cable.

Cuando un valor lo decide un proveedor y no tú, dilo en la misma línea. Un prefijo delegado por una empresa de alojamiento tiene un proceso de cambio distinto que uno que elegiste tú. Esa nota ahorra al siguiente ingeniero un ticket de soporte durante un incidente. También explica por qué un cambio que aprobaste no tuvo efecto.

Describe qué se rompe y cómo te recuperas

Para cada etapa de la ruta, indica qué se detiene cuando desaparece el túnel y qué conexión saliente debe seguir siendo alcanzable para que puedas arreglarlo. Un diseño que pierde su acceso de gestión junto con el túnel es un diseño que exige una visita al sitio.

El túnel completo y el túnel dividido pertenecen a esta página como una elección explícita y no como una casilla, porque cambian tanto el modo de fallo como la ruta de recuperación.

Nombra una prueba inocua para cada etapa

La alcanzabilidad del extremo, el establecimiento del túnel, la dirección privada, el nombre privado y el permiso de la aplicación son cinco observaciones distintas, y cada una necesita una prueba que no pueda confundirse con otra. Un ping a la pasarela demuestra las dos primeras como mucho. Una conexión al puerto de la aplicación demuestra la cuarta y la quinta solo si el nombre se resolvió mediante el resolutor previsto.

Escribe la prueba junto a la etapa que cubre, incluido el comando y la salida esperada. Una página de rutas precisas supera a una página de comandos que nunca dice qué paquetes debían afectar.