CIDR de grupo en Access Server: direcciones de miembro o red de recursos

Dos campos de un grupo de Access Server aceptan un CIDR y, a primera vista, parecen el mismo tipo de entrada: uno describe las direcciones que se entregan a los miembros de la VPN y el otro describe las redes a las que esos miembros pueden llegar. Si rellena el campo equivocado, el sistema lo acepta sin mostrar ningún error, y eso es justo lo que hace caro el fallo. El primero cambia su plan de direccionamiento del túnel; el segundo decide qué destinos están permitidos, y ninguno de los dos implica al otro. Hay además un tercer objeto que la gente mete en estos dos, la subred que está detrás de una puerta de enlace de sucursal, y no pertenece a ninguno de los dos campos.

La misma sintaxis, preguntas distintas

Pregunte qué está nombrando el valor. Un CIDR de direcciones de miembro responde a la pregunta de qué direcciones internas reciben los clientes que se conectan, y la maquinaria de asignación lo consume antes de que fluya ningún tráfico. Un CIDR de recurso responde a qué destinos puede usar este grupo, y las reglas de acceso lo consumen cuando se evalúa un paquete. Uno es la definición de un fondo de direcciones, el otro es un permiso.

Las consecuencias de confundirlos son opuestas. Una LAN de destino pegada en el campo del fondo puede repartir direcciones que ya existen en esa LAN, lo que produce un comportamiento de direcciones duplicadas, o puede desplazar el fondo de tal forma que rompa en silencio todas las reglas de cortafuegos escritas contra el rango anterior. Un fondo pegado en una regla de acceso no concede nada útil, porque ahí no vive ningún destino. Los dos errores se presentan igual: el túnel está levantado pero algo va mal.

Asignación: el espacio de direcciones de los miembros

El fondo no debe solaparse con ninguna LAN a la que un miembro pueda llegar ni con ningún otro fondo de VPN del despliegue. Es una restricción de planificación, no un ajuste del producto: con dos sedes que usan 10.90.40.0/24 para los miembros, un miembro de una sede no puede encaminar hacia la otra sin traducción, y ninguna regla de acceso lo arregla.

El modo de asignación también importa. Un fondo dinámico entrega a cada miembro la siguiente dirección libre, mientras que una asignación estática por usuario la fija. La asignación estática es lo que quiere cuando las reglas de cortafuegos o la monitorización se refieren a miembros concretos, y además hace visible un cambio del plan de direcciones: la dirección fijada sigue dentro del nuevo fondo o ya no está. Lea la dirección de túnel de un miembro conectado antes y después de cualquier cambio en este campo.

Permiso: las redes de destino van en las reglas de acceso

La alcanzabilidad se expresa en las reglas de acceso, que nombran el grupo o los usuarios, una red o un servicio de destino y el método de acceso. Esa última parte es donde mueren la mayoría de las configuraciones a medio terminar: una regla puede encaminar el tráfico hacia el destino o aplicarle NAT, y las dos cosas piden condiciones distintas a la red. Una ruta encaminada exige que el lado del destino sepa devolver el tráfico al fondo de la VPN, mientras que una ruta con NAT esconde a los miembros detrás de una dirección en la que el destino ya confía. La documentación de grupos de Access Server mantiene la red del grupo separada de sus reglas de acceso, y las etiquetas han cambiado entre versiones.

Un destino permitido sigue necesitando una ruta utilizable. La regla permite, la ruta entrega, el camino de vuelta responde y el servicio del host acepta. Cuatro cosas, cuatro sitios donde mirar, y solo la primera vive en la regla de acceso. Un permiso en verde con un traceroute muerto suele significar que falta la ruta de retorno en la puerta de enlace del destino, no que la regla esté mal.

El tercer objeto: una subred de sucursal detrás de una puerta de enlace

Declarar que un cliente concreto es propietario de una subred es una afirmación de encaminamiento sobre una sede, no una asignación de direcciones ni un permiso. En términos de Access Server es la configuración de puerta de enlace admitida para una red que se conecta, y existe porque un router de sucursal puede anunciar la LAN que tiene detrás. Los miembros siguen recibiendo direcciones del fondo y siguen necesitando una regla de acceso para usar esa LAN de sucursal.

Mantener los tres objetos separados compensa durante la revisión. Una subred de sucursal apuntada como espacio de direcciones de miembro del grupo parece correcta en una captura de pantalla y rompe la asignación para todos los del grupo. Esa misma subred anotada solo en una regla de acceso concede acceso sin la declaración de propiedad, así que el tráfico de vuelta no tiene adónde ir. Ponga cada objeto en su propia columna del diseño y el error deja de ser posible.

Cómo saber cuál está mirando

Lea la etiqueta junto con sus vecinas. Un campo junto a un modo de asignación, un tamaño de fondo o una excepción por usuario trata de asignación. Un campo junto a un selector de grupo, un servicio o puerto y un método de encaminamiento trata de permiso. Las versiones renombran cosas, pero las vecinas se quedan más o menos donde estaban, y por eso el texto de una captura antigua es una mala guía de navegación.

Después verifique con un solo miembro en lugar de con todo el grupo: su grupo efectivo, su dirección de túnel asignada y la regla que autoriza el destino que pretende. Confirme la ruta, el NAT o la ruta encaminada, el tráfico de vuelta y el permiso del servicio en ese orden, y cambie solo el campo que coincide con la discrepancia demostrada. Mantenga después los registros de asignación y de permiso separados, para que un cambio posterior del fondo no se lea como un cambio en lo que el grupo puede alcanzar.