Extensión del sitio VPN: siga la ruta de vuelta más allá de la puerta de enlace

El tráfico de una sucursal termina en una puerta de enlace cuya LAN no contiene la aplicación a la que se le pidió llegar. El servidor está en un segundo centro de datos, al otro lado de un enlace interno que la VPN nunca configuró. Añadir otro prefijo a la puerta de enlace cercana no hace nada para ese caso, porque la puerta de enlace lejana es un punto final de cifrado y no el último enrutador. El camino necesita una ruta hacia delante, una admisión en la frontera de seguridad lejana y una decisión de retorno en la propia red del destino.

La puerta de enlace lejana es un punto final de cifrado

El IPsec de puerta a puerta protege el tráfico entre dos dispositivos de seguridad, y las direcciones internas viajan cifradas por ese segmento. Más allá de la puerta de enlace lejana, asume el control el enrutamiento ordinario, incluida cualquier política que exista entre centros de datos. El segmento protegido cubre, por tanto, parte del trayecto y no el resto. Suponer lo contrario es como un diseño acaba con un túnel sano y una aplicación inalcanzable.

Dibuje el camino en tres tramos: sucursal a puerta de enlace cercana, cercana a lejana, lejana a la aplicación. Cada tramo tiene su propio dueño y su propio modo de fallo.

Lea las dos direcciones de la política del túnel

La política del túnel suele escribirse desde la perspectiva del lado local, y de esa costumbre vienen las configuraciones parciales. Ambos pares deben listar el origen de la sucursal y el destino tal como aparecerán dentro del túnel, incluida cualquier traducción que el diseño pretenda. Actualizar solo el extremo cercano produce un desajuste de fase dos que parece un fallo de enrutamiento. Compare los dos conjuntos de políticas antes de tocar cualquier ruta.

Escriba origen y destino como direcciones en lugar de nombres de sitio. La ambigüedad aquí reaparece más tarde como una asimetría desconcertante.

Añada la ruta hacia delante y confirme la admisión

La puerta de enlace lejana necesita una ruta hacia la subred de la aplicación, y cada enrutador entre ambas debe admitir el origen de la sucursal. Verifique lo que la puerta de enlace lejana tiene realmente en lugar de lo que afirma el diagrama.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

El primer comando informa de la interfaz de salida y del siguiente salto que la puerta de enlace lejana elegiría para ese origen, una pregunta que una tabla de enrutamiento simple no puede responder. El trazado muestra dónde se detienen los paquetes, y una interrupción después de la puerta de enlace lejana apunta al tránsito interno y no al túnel. Cuando la ruta existe y el tráfico sigue desapareciendo, capture en la puerta de enlace lejana y lea la dirección de origen que llega, porque una dirección inesperada significa que la traducción ocurre en algún lugar no planificado. Todas las direcciones de aquí son marcadores, así que sustituya las subredes reales de sucursal, tránsito y aplicación.

Pruebe desde la sucursal y luego vuelva a probar el camino antiguo

La aceptación necesita un origen real en lugar de una sonda desde la puerta de enlace lejana. Ejecute la comprobación desde un equipo de la sucursal y mantenga los destinos que ya funcionaban en la misma prueba.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Una respuesta de la aplicación demuestra el camino de ida y el de vuelta a la vez, mientras que el ping al destino antiguo demuestra que el cambio no rompió lo que ya funcionaba. Capture la dirección de origen que registra la aplicación, porque sus reglas de acceso y cualquier ruta de retorno deben coincidir con ese valor. Donde la sucursal traduce antes del túnel, la dirección de la política y la dirección que ve la aplicación difieren por diseño, así que registre ambas. Repita la prueba tras una renovación de clave o un cambio de enrutamiento, porque estos caminos suelen validarse una vez y luego olvidarse.

Asigne un dueño a cada uno de los tres segmentos y a la ruta de retorno dentro de la red de destino. Un camino con cuatro dueños falla en los huecos entre ellos.