Dos oficinas usan ambas 192.168.1.0/24 porque nadie planificó otra cosa, y se espera que el túnel lo resuelva. No puede: un enrutador no puede hacer que la misma dirección privada signifique dos lugares distintos. El trabajo que lo evita ocurre antes de que se escriba el primer parámetro del túnel.

Inventaríe cada rango, incluidos los que olvidó

Reúna las LAN, los segmentos de servidores, los grupos de clientes de acceso remoto, los rangos de VPC en la nube y cualquier red de contenedores o superpuesta a la que los equipos deban llegar. Los grupos de clientes son los que la gente olvida, y se solapan con un rango de oficina sorprendentemente a menudo porque ambos se eligieron del mismo valor predeterminado. Incluya la red de gestión y cualquier segmento fuera de banda.

Anote el propietario, la puerta de enlace, el propósito y si el prefijo debe ser alcanzable desde la otra sede. Un prefijo que nunca necesita cruzar el túnel no tiene que ser único, y saberlo reduce el trabajo de renumeración.

Haga IPv6 por separado, porque su plan y sus solapamientos son independientes.

Compare prefijos, no direcciones familiares

Dos redes con direcciones de host distintas pueden solaparse igualmente, porque el solapamiento es una propiedad de las máscaras y no de los números que la gente recuerda. 10.20.0.0/16 contiene 10.20.30.0/24 lo diga alguien en voz alta o no. Compare pares de prefijos completos y compruebe los agregados contra las redes más pequeñas que hay dentro. Por eso la comprobación pertenece a una hoja de cálculo y no a la cabeza de nadie.

La misma comprobación se aplica al grupo de clientes de la propia VPN y a cualquier rango traducido que piense introducir, ya que un rango traducido que colisiona es peor que el solapamiento original.

Basta una tabla de prefijos con máscaras; un diagrama sin máscaras no.

Decida qué tiene que cruzar de verdad

Una sede puede contener treinta subredes mientras que una red de servicio necesita acceso remoto. Parta de ese requisito y anuncie solo lo que necesita, porque los anuncios más pequeños y las reglas de acceso correspondientes son más fáciles de revisar y más difíciles de ampliar por accidente. Anunciar todos los rangos privados en uso es una costumbre que convierte un túnel en un puente. Cuanto más estrecho el anuncio, menor el radio de impacto de un error futuro.

El DNS privado tiene que devolver direcciones que los clientes previstos puedan alcanzar, así que un nombre que apunta a un rango no anunciado o solapado sigue roto aunque la consulta tenga éxito.

Escriba la lista de acceso antes de la configuración del túnel, no después de que falle.

Renumere o traduzca, y conozca el coste

Renumerar una red suele ser el remedio más claro a largo plazo, y toca reservas, dispositivos, DNS, reglas de cortafuegos y todo lo que tenga una dirección incrustada en una configuración. Traducir un rango de acceso es la alternativa cuando renumerar no es práctico, y cuesta la identidad de origen más una clase de protocolos que incrustan direcciones en la carga útil. Elija una y termínela, porque una red a medio renumerar es peor que cualquiera de las dos opciones.

Elija lo que elija, documente tanto la dirección original como la presentada, porque cada conversación posterior de resolución de problemas las necesita.

Un apaño sin ruta de vuelta no es un apaño.

Use una matriz de rutas como prueba de aceptación

Termine con una matriz: prefijo local, prefijo remoto, servicio permitido y puerta de enlace de retorno. Esa tabla es la prueba de aceptación cuando el túnel levanta, y también es el documento que leerá el siguiente ingeniero. Pruebe desde equipos reales en las subredes elegidas y no desde las puertas de enlace.

Un ping entre direcciones del túnel demuestra que el túnel existe y nada sobre el plan de direcciones que hay detrás.

Guarde la matriz con la configuración del túnel, y la siguiente adición de sede empezará a partir de datos y no de memoria. La guía de reenvío de strongSwan cubre el lado de la puerta de enlace una vez que el plan existe.

Artículos relacionados