Qué registrar para una VPN de sitio a sitio: selectores y alcance

Seis meses después de poner en marcha un túnel, una subred nueva deja de coincidir con la política y el único documento compartido dice VPN de oficina. Ese es el fallo que evita un registro de selectores, y es concreto: un conjunto de direcciones cambió mientras el papeleo no. Escribir bien el registro significa saber cuál de varios conjuntos de direcciones está describiendo, y anotar el que el extremo opuesto aplica de verdad en lugar del que configuró.

Configurado no es negociado

En un túnel IPsec basado en políticas, cada lado propone selectores de tráfico: rangos de origen y destino para la asociación hija. El lado que responde puede estrechar esa propuesta , así que la asociación instalada puede cubrir menos de lo que enumera la configuración. Un registro que copia la configuración describe, por tanto, una intención, no el alcance de protección actual. Los dos divergen en silencio, y nada en la página de estado del túnel lo señala.

Conserve ambas columnas, con la fecha en que las observó. El selector configurado es lo que usted quería; el negociado es lo que el núcleo aplica ahora mismo. Cuando difieren, esa diferencia explica un fallo sorprendente mucho más a menudo que un error de enrutamiento.

Una asociación tampoco representa todos los pares configurados. Un túnel con varias combinaciones de selectores puede acabar con varias asociaciones hijas, y un registro que enumera una de ellas es un inventario parcial. Enumérelas en lugar de resumirlas.

Los túneles basados en rutas seleccionan de otra manera

Con una interfaz basada en rutas, la tabla de enrutamiento decide qué entra en el túnel y los selectores pueden ser deliberadamente amplios. Es un diseño legítimo y no un descuido, y el registro debe describirlo como tal. Anote la ruta, la interfaz a la que apunta y la política de cortafuegos que limita qué servicios son alcanzables. El alcance de protección es amplio a propósito, y el alcance del servicio hace el estrechamiento.

Copiar una plantilla basada en políticas en un túnel basado en rutas produce un documento que describe un mecanismo que el despliegue no usa. El siguiente ingeniero busca entonces selectores que nunca debieron estar ahí, y concluye que el túnel está mal configurado cuando solo está mal documentado.

La traducción pertenece a la misma tabla

Cuando el NAT presenta un rango distinto al extremo opuesto, registre los prefijos originales y traducidos juntos. Anote la etapa en la que los selectores y las reglas de acceso coinciden con ellos, porque el orden decide si el lado remoto llega a ver la dirección que usted anotó. Una tabla con solo uno de los dos rangos es peor que ninguna tabla, porque parece completa.

Este es el detalle que rompe un túnel que funcionaba tras un cambio de NAT: el selector sigue coincidiendo con el prefijo original, el extremo opuesto recibe ahora uno traducido, y su ruta de retorno apunta a una dirección que ya no existe. Nada registra un error en el momento en que los dos dejan de coincidir.

El DNS privado pertenece al mismo sitio. Un nombre que resuelve a una dirección inutilizable desde el sitio correspondiente es un error de documentación con un tique de soporte adjunto, y se culpará al túnel.

Adjunte el requisito de servicio

Un rango protegido no es una lista de permisos. Anote qué servicios deben ser alcanzables desde qué origen, y quién es el propietario de la aplicación que hay detrás. Esos dos campos responden a preguntas distintas, y confundirlos es como una revisión de seguridad acaba discutiendo de enrutamiento en lugar de acceso.

Después nombre al administrador de red que mantiene la regla. Un inventario de selectores sin propietario queda obsoleto en silencio, y lo obsoleto no se distingue de lo incorrecto cuando el túnel se rompe a las dos de la madrugada. El propietario es también la persona que puede confirmar que un cambio fue deliberado.

Convierta el registro en un plan de pruebas

Para cada ruta necesaria, elija un host de origen y otro de destino representativos y anote la ruta, el servicio y la puerta de enlace de respuesta esperados. Eso convierte el documento en un plan de pruebas en lugar de una descripción. Lea la asociación viva con el comando de abajo, y compárela con la fila negociada que anotó.

swanctl --list-sas

Un esqueleto de cinco líneas suele bastar para mantener el registro honesto. La versión de abajo cabe en un tique de cambio sin recortes:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Un ping solo a la puerta de enlace no es la prueba de aceptación. Nunca ejercita la ruta de tránsito, así que puede pasar mientras todos los flujos reenviados fallan. Pruebe desde un host de un lado a un servicio del otro y confirme que la respuesta llega por el túnel. Si solo pasa el ping, el registro acaba de encontrar el problema de reenvío que debía prevenir. documentación de reenvío de strongSwan explica cómo interactúan los selectores, las rutas y el reenvío en un extremo Linux.