Un selector IPsec amplio no es permiso para cada servicio

Dos extremos acuerdan proteger toda una subred y alguien lee ese acuerdo como permiso para llegar a cada servicio dentro de ella. Ese es el mito: el selector dice qué tráfico el túnel está dispuesto a transportar y no dice nada sobre qué servicios permite la organización. Un par de dispositivos puede negociar legítimamente un rango de direcciones amplio mientras la política de acceso dentro de él permite dos puertos, y ambas afirmaciones siguen siendo ciertas a la vez.

La cobertura protegida no es autorización

Un selector de tráfico forma parte del acuerdo del túnel. Restringe o confirma qué cifrarán los extremos entre sí, y un selector amplio suele ser lo más sencillo de operar cuando ambos lados tienen muchos flujos que transportar. El filtro de servicios es otro control en otro punto del camino y decide qué se puede usar realmente una vez descifrado el paquete. Quitar el filtro para que pase una prueba convierte una decisión de política en un accidente.

Mantenga los dos registros separados en el documento de diseño, porque un lector que solo ve el selector inferirá una autorización que nunca se concedió. Dos líneas en un registro de cambios lo evitan y llevan menos tiempo que la discusión que sigue.

Describa un flujo desde ambos extremos

Anote el iniciador, el respondedor, el origen y el destino tal como se presentan, el protocolo y ambos puertos. Después invierta cada una de esas etiquetas para el otro extremo, porque el puerto de origen efímero de un cliente pasa a ser el puerto de destino de una respuesta y la red remota se convierte en la local. Una configuración copiada de un lado al otro sin esa inversión es la forma en que los filtros acaban permitiendo exactamente la dirección equivocada. Escriba la tabla una vez y construya ambos filtros a partir de ella.

Acuerde el modelo de selección antes de copiar nada, porque un diseño basado en políticas y un diseño basado en rutas expresan la misma intención mediante objetos distintos. Escriba el nombre del modelo junto al flujo, o el siguiente ingeniero pasará una tarde emparejando objetos que nunca fueron comparables.

Encuentre el filtro que realmente se aplica

En un ASA, el filtro VPN es una ACL asociada a una política de grupo y aplicada al tráfico después del descifrado y antes del cifrado. La documentación de políticas de grupo de Cisco también describe la herencia, incluido un valor a nivel de usuario que reemplaza el valor de la política de grupo. Así que la ACL que editó puede no ser la ACL que gobierna la sesión que tiene delante. Lo mismo ocurre con el objeto de usuario, que puede imponerse al grupo sin dejar rastro visible apreciable.

Inspeccione la sesión efectiva en lugar del objeto que recuerda haber cambiado, y anote qué objeto de política la proporciona. Ese único paso resuelve una cantidad sorprendente de informes del tipo el filtro es correcto pero no funciona.

Dirección, puertos y el caso inverso

La convención documentada coloca la red remota, o las direcciones asignadas a los clientes remotos, en la posición de origen y la red local en la posición de destino, con las respuestas expresadas intercambiando las posiciones de las direcciones. Las reglas de puertos se apoyan en esa convención y merecen más cuidado que las direcciones.

El modelo documentado puede permitir que una regla de puerto de destino afecte a una iniciación inversa que usa ese mismo puerto de origen, lo que significa que el filtro no es simplemente una regla de petición unidireccional con respuestas inofensivas adjuntas. Razone explícitamente ambas direcciones de iniciación e incluya el caso que pretende denegar.

La misma documentación limita el filtro a las conexiones iniciales, así que no es una aplicación universal de cada canal secundario que abre una aplicación inspeccionada. Cuando la política completa necesita esa cobertura, pertenece a un límite aparte en lugar de a una ACL estirada más allá de su propósito.

Pruebe tres casos antes de darlo por terminado

Acepte el flujo previsto, rechace un servicio que la política prohíbe y ejercite el caso de dirección inversa que razonó. Ejecútelos bajo un plan aprobado con las mismas identidades y selectores que va a desplegar. Una prueba que solo muestra que el servicio permitido funciona demuestra el túnel, no la política.

Mantenga la cobertura negociada y la decisión de acceso como dos registros, porque explicar qué permite una VPN requiere ambos.