Grupos de direcciones VPN de doble pila: atender ambas familias en strongSwan

Una puerta de enlace puede entregar a un usuario nómada tanto una dirección virtual IPv4 como una IPv6 mientras el túnel externo sigue viajando por IPv4. Son decisiones independientes, y tratarlas como una sola es donde suelen venirse abajo los planes de doble pila. Las familias internas del cliente, los prefijos protegidos que puede alcanzar y el transporte que lleva la encapsulación son tres elecciones separadas.

La mayor parte de la confusión viene de aplicar la expresión doble pila a un diseño que es de doble pila solo en un lugar. Un servicio puede ser de doble pila internamente, de pila única en su dirección exterior, y aun así funcionar perfectamente bien para los clientes. Lo que no puede es funcionar por casualidad.

Dos familias dentro, un solo camino fuera

La conexión exterior es IKE sobre UDP, y necesita una familia de direcciones accesible desde dondequiera que esté el cliente. Una dirección IPv6 interna no exige un proveedor con IPv6, porque el paquete interno es carga útil dentro del externo. Muchos despliegues que funcionan transportan prefijos IPv6 por un enlace ascendente solo IPv4.

Lo que sí limita el camino exterior es la accesibilidad y el tránsito por NAT. Si la puerta de enlace anuncia solo una dirección IPv4, un cliente en una red solo IPv6 no puede conectarse en absoluto, por muchos grupos que haya configurado. Decida la familia exterior según su población de clientes, no según el plan de direcciones interno.

Dé al cliente una dirección en cada familia

Solicitar ambas familias es una sola línea en el lado del cliente, siempre que la puerta de enlace tenga algo que repartir. Los grupos con nombre mantienen las fuentes separadas de las redes de servicio, y esa es la propiedad que hace legibles las reglas de cortafuegos seis meses después.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

El vips valor pide una dirección de cada familia, y la lista de grupos decide de dónde vienen esas direcciones. La documentación de strongSwan sobre IP virtual cubre varias solicitudes y la asignación de grupos, incluido el punto de que un cliente que pide una dirección concreta expresa una preferencia que el respondedor puede anular. No construya una regla de acceso que suponga que el cliente recibe siempre el mismo valor.

Genere su propio prefijo local único en lugar de copiar el del ejemplo. Dos organizaciones que ambas fd42::/16 lo desplieguen descubrirán la colisión la primera vez que se interconecten, y diagnosticarlo no es agradable.

Los selectores describen destinos, no fuentes

Los selectores de tráfico locales de la SA hija dicen qué redes protegidas están detrás de la puerta de enlace, y los selectores remotos describen qué puede usar el cliente como fuente. Una dirección de grupo virtual pertenece al lado de origen de esa política; ponerla en la lista de destinos es una mala lectura habitual de la configuración.

Ambas familias necesitan rutas de retorno y reenvío permitido en la puerta de enlace. Añadir un prefijo a un selector sin una ruta de vuelta al grupo produce un túnel que se establece, pasa una sola dirección del tráfico y descarta la respuesta en silencio. El selector es política, no enrutamiento.

Mantenga los grupos y los prefijos de servicio en bloques separados de su plan de direcciones. Cuando se solapan, una ruta que debería llegar a un host protegido puede coincidir con una dirección de grupo y desaparecer dentro del túnel.

El DNS y el camino de respuesta deciden si parece terminado

Las respuestas del resolutor son independientes del transporte usado para llegar a él. Un nombre puede devolver un registro A, un registro AAAA o ambos, y el cliente elige según sus propias reglas de preferencia . Si un servicio interno publica un registro AAAA pero nada enruta ese prefijo, los clientes en redes de doble pila probarán primero el camino IPv6 y se quedarán ahí hasta que falle. Nada en la configuración del túnel parece incorrecto mientras eso ocurre.

Así que decida por nombre qué familias deberían ser utilizables y luego compruebe que el prefijo correspondiente está en el selector y tiene una ruta de retorno. Es una decisión servicio por servicio. Publicar ambos tipos de registro sin distinción es como un servicio que funciona solo con IPv4 empieza a agotar el tiempo de espera para la mitad de sus usuarios.

Verifique ambas familias antes de darlo por hecho

Una configuración que carga no es una configuración que funciona. Lea el estado que informa el demonio, confirme las asignaciones de grupo y luego mire las rutas que el cliente instaló realmente.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Los dos primeros comandos muestran las SA hijas establecidas y qué grupos aún tienen direcciones disponibles, de modo que un plan que funciona para el primer cliente y falla para el décimo se hace visible. Los dos últimos muestran si el cliente recibió una dirección IPv6 global del grupo y adónde iría realmente el tráfico hacia un prefijo protegido. Compare la dirección asignada con el grupo que configuró, no con la dirección que esperaba. Si el respondedor eligió un valor distinto según su política, las rutas y las reglas de cortafuegos deben seguir encajando con lo que eligió.

Después pruebe un host protegido por familia, y pruebe un nombre que resuelva a ambas. Una prueba de una sola familia no le dice nada sobre la mitad del plan que no ha ejercitado, y esa mitad suele ser donde vive la ruta que falta.