Cómo mantener legible un plan de direcciones IPv6 VPN un año después
Un plan legible dice qué prefijo pertenece a qué sitio y cómo vuelven las respuestas. Anote roles, notación, delegación y rutas de retorno junto a cada entrada.
Dos preguntas deciden si un plan de direcciones merece su lugar: qué prefijo pertenece a qué sitio y cómo sale una respuesta de ese sitio. Responda ambas de una vez y quien mantiene el sistema podrá cambiar un par sin interrogar a nadie. Todo lo demás en el documento existe para sostener esas dos respuestas. Lo que no sostiene ninguna es decoración.
Qué debe responder un lector antes de tocar un par
La compresión hace que las direcciones parezcan ordenadas, y el orden no es estructura. Estructura es saber qué rango delegó el proveedor, cuál eligió usted, cuál es un grupo de clientes y cuál se sienta detrás de un sitio.
Escriba para el colega que se incorpora el próximo trimestre y debe añadir un segundo sitio. Nada en la página le dice de dónde vino un prefijo si la entrada no lo hace. Omítalo y el primer cambio se convierte en arqueología.
Qué debe portar cada línea del plan
Cuatro campos hacen una entrada revisable: cuánto mide el prefijo, quién lo posee, adónde va el tráfico después y qué componente entrega el valor. Confróntelos con la configuración en marcha y cualquier desacuerdo sale solo. Un siguiente salto hacia un túnel retirado el mes pasado parece incorrecto de inmediato en vez de fundirse con el fondo.
Mantenga los roles en filas separadas aunque hoy dos de ellos compartan un prefijo. Fusionarlos hace que una separación posterior se lea como una asignación nueva y no como una corrección.
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains a reply that never arrives |
Dónde divergen el texto canónico y la sintaxis de configuración
RFC 5952 fija una forma textual para una dirección: minúsculas, sin ceros iniciales y la serie más larga de grupos cero comprimida exactamente una vez. Úsela en notas, tiques y registros de cambios para que dos documentos se comparen sin conversión. Quien encuentra dos grafías de una misma dirección empieza a buscar una diferencia que no existe. La coherencia aquí es barata y elimina toda una clase de falsas alarmas.
Los archivos de configuración obedecen sus propias reglas, y no son las de legibilidad. Una dirección emparejada con un puerto necesita corchetes aunque la dirección desnuda no los necesite, y copiar de una nota a un archivo de configuración pierde esa distinción sin avisar. Nombre la forma que usa cada campo, o el plan provocará el error de transcripción que debía evitar.
Dos notaciones están bien siempre que cada una esté etiquetada. La mezcla sin etiquetar es lo que invita al error.
Dónde aparecen rangos superpuestos y rutas de retorno ausentes
La superposición sobrevive más que otros errores porque nada parece mal hasta que dos sitios responden por el mismo rango. Etiquete el sitio y genere prefijos locales únicos mediante el procedimiento documentado en lugar de copiar un ejemplo.
Una lista de clientes nunca explica en qué dirección viaja la respuesta. Anote el camino de vuelta de la puerta de enlace LAN junto al rango de par que lleva el túnel, y el registro explicará una subred remota que recibe peticiones y se queda callada. Ejecute las comprobaciones de abajo en la máquina y compárelas con la entrada. Un plan que no concuerda con ip -6 route es un plan que la gente deja de leer.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0El alcance no es autorización, y un prefijo nunca implica una política. Escriba el acceso previsto junto a la ruta a la que se aplica. Si no, el siguiente lector trata una dirección del plan como permiso para llegar a cada servicio que hay detrás.
Cómo sobrevive el plan al tercer sitio
Marque cada prefijo como delegado, asignado localmente o encaminado de otra forma. Para todo lo que pueda moverse, nombre el proceso que lo mueve. Luego enumere los registros DNS y las reglas de cortafuegos que deben cambiar en la misma ventana, porque una actualización de prefijo que se detiene en el router está medio hecha.
Tras un cambio, llegue a un recurso detrás de cada límite que el cambio tocó antes de editar el documento. Un plan que describe la red del mes pasado es peor que ninguno, porque la gente confía en él. Mantenga las asignaciones retiradas listadas con la fecha en que desaparecieron para que nadie las reemita por accidente. Los secretos quedan fuera del archivo; un plan explica la red, no la abre.
Guarde el plan donde se revisan los cambios, junto a la configuración que describe. Un documento que nadie relee se pudre más rápido que la red que dibuja.