Planifique los rangos privados de direcciones VPN antes de que los sitios colisionen
Los rangos privados superpuestos rompen el enrutamiento antes de cualquier túnel. Inventaríe los prefijos, dimensione los grupos de clientes aparte de las LAN de los sitios y pruebe desde el lado remoto.
Dos sitios que usan ambos 192.168.1.0/24 pueden llegar a internet y, aun así, no llegar el uno al otro. La puerta de enlace no genera ningún error; instala una ruta para ese prefijo y envía cada paquete al par que lo reclamó primero. Nada en el handshake, la lista de cifrados ni la métrica de la interfaz dice qué par está equivocado. La planificación de direcciones es la parte del diseño que resuelve esto antes de que nadie se conecte.
Inventaríe cada espacio que deba ser accesible
Anote los rangos que deben enrutarse, no solo los que está configurando. Eso significa las LAN de los sitios, los grupos de clientes VPN, las subredes en la nube, las redes de gestión y fuera de banda, los segmentos de laboratorio y las redes desde las que los usuarios suelen conectarse en casa. Un router de consumo que se entrega como 192.168.1.0/24 no es hipotético, y el mismo prefijo aparece en hoteles y recintos de congresos. El inventario es una tabla de prefijo, propietario y propósito, y es el único artefacto que evita que el mismo rango se entregue dos veces.
| Prefix | Purpose | Owner |
|---|---|---|
| 10.20.0.0/16 | site LANs | network team |
| 10.20.100.0/22 | VPN client pool | remote access |
| 10.20.200.0/24 | management | operations |
Añada los prefijos que espera durante el próximo año, porque un plan que solo cubre hoy falla en el primer sitio nuevo. Marque cada fila con quién puede cambiarla, no solo con quién la posee.
La reutilización es lo que lo hace difícil: el espacio privado es finito y cada organización considera 10.0.0.0/8 como suyo. Un plan no puede prometer que ninguna LAN de invitados futura caiga en uno de sus prefijos, así que el diseño tiene que decir qué ocurre cuando lo hace. Dos reglas hacen la mayor parte del trabajo. Ponga los grupos de clientes en un bloque contiguo que pueda resumir, y no asigne nunca un rango que otro equipo ya enruta. Todo lo demás es un registro que alguien mantiene al día.
Por qué una superposición derrota la tabla de enrutamiento
Una ruta es un prefijo más un siguiente salto, y el reenvío elige el prefijo coincidente más largo. Cuando dos pares reclaman ambos 192.168.1.0/24, la tabla guarda una sola entrada para él, así que el tráfico de ambos sitios sale por el mismo túnel. El segundo sitio no está mal configurado; es inalcanzable porque el primero responde por las mismas direcciones. Ninguna métrica puede separarlos, porque la coincidencia ocurre antes de consultar las métricas.
El fallo es asimétrico y fácil de malinterpretar. Los hosts del sitio A llegan a la puerta de enlace y a algunos servicios, mientras que los del sitio B no responden nada, y el registro muestra un túnel sano en ambas direcciones. Ese patrón es una colisión de direcciones y no una falla de autenticación o del cortafuegos, y confirmarlo requiere un volcado de la tabla comparado con el inventario.
Dimensione deliberadamente el grupo de clientes y los rangos de los sitios
Un grupo de clientes VPN es un rango que la puerta de enlace entrega una dirección a la vez, así que su tamaño limita la concurrencia. Un /24 alberga 254 direcciones utilizables, lo que es generoso para un equipo pequeño y ajustado para una sucursal que ejecuta contenedores; un /22 no cuesta nada extra dentro del espacio privado y elimina la discusión. Mantenga el grupo contiguo y alejado de cada LAN de sitio, para que la ruta resumida hacia los clientes nunca se trague un sitio. Reserve el rango incluso mientras el grupo está vacío, porque un rango sin escribir es el que asignará el siguiente ingeniero.
Los sitios reciben rangos dimensionados para los hosts esperados más el crecimiento, alineados en un límite que se resume limpiamente. Los huecos deliberados entre asignaciones no cuestan nada y compran espacio para agregar más adelante.
Después compruebe la dirección que la gente olvida: el camino de vuelta. Cada router de sitio necesita una ruta hacia el grupo de clientes, y el concentrador necesita una ruta hacia cada prefijo de sitio que sirve. Una tabla de prefijos ordenada sin camino de vuelta al grupo sigue siendo un diseño roto, y el síntoma es una conexión unidireccional que no responde nada. Mantenga ambas direcciones en la misma tabla y revísela cada vez que se añada un sitio.
La traducción y la renumeración resuelven problemas distintos
Cuando ya existe una superposición, hay dos opciones honestas y una deshonesta. La renumeración elimina la colisión de forma permanente y cuesta una ventana de mantenimiento más cada dirección codificada que haya olvidado. La traducción de direcciones asigna el rango privado de un lado a otro rango en el borde del túnel, lo que deja ambos sitios intactos pero añade estado, rompe protocolos que incrustan direcciones y hace los registros más difíciles de leer. La opción deshonesta es una ruta de host hacia un solo servidor, que pasa una prueba y falla todo lo demás.
Elija por control y vida útil. Un sitio que posee y puede programar pertenece al camino de la renumeración; una red de socio que no puede tocar, usada para una sola aplicación, es candidata a traducción con una correspondencia documentada. Escriba esa correspondencia, porque una traducción que solo existe dentro de un archivo de configuración desaparece en el momento en que el archivo se reemplaza.
Pruebe desde el lado remoto antes de desplegar
Pruebe desde una red que no aloje la puerta de enlace, porque la LAN propia de la puerta de enlace oculta la mayoría de los errores de enrutamiento. Conecte un cliente detrás de un router doméstico corriente y luego llegue a un servicio en cada sitio y a uno dentro del grupo de clientes. Pruebe también la dirección inversa, desde un host de sitio hasta el cliente, porque los caminos de vuelta fallan de forma independiente. Una prueba que solo hace ping a la puerta de enlace demuestra que el túnel está levantado y nada más.
Mantenga rangos, propietarios y correspondencias de traducción en un único registro compartido que el siguiente sitio lea antes de asignar nada. Revíselo cuando se añada un sitio y trate un rango no documentado como un defecto y no como una sorpresa.
El registro es el entregable. Un plan que vive en la memoria de tres personas falla la primera vez que uno de ellos está de vacaciones, y una superposición encontrada en producción cuesta más de lo que habría costado la tabla.