strongSwan vips: pedir una dirección virtual a IKEv2

Tu cliente IKEv2 puede pedir a la puerta de enlace una dirección interna, y la puerta de enlace decide qué devolver. En strongSwan, esa petición es el ajuste vips, y sigue siendo una petición incluso cuando escribes en él una dirección concreta. La guía siguiente configura la petición, la carga y lee lo que volvió, porque esos tres pasos fallan de tres maneras distintas. Ninguno de ellos se acorta por teclear con más fuerza.

Qué pide vips y qué no puede prometer

vips pertenece dentro de una definición de conexión y pide al respondedor una dirección virtual. La guía de direcciones virtuales de strongSwan es explícita en que la respuesta puede ser otra dirección, o nada en absoluto, y esa es la frase que la gente se salta cuando escribe un valor y espera que aparezca. La petición sigue mereciendo la pena, porque lo que verificas es la respuesta. Trata el ajuste como una instrucción para preguntar, no como la configuración del resultado.

Pedir 0.0.0.0 solicita cualquier dirección virtual IPv4 disponible, lo que normalmente es correcto cuando el valor exacto no importa. Pedir una dirección concreta es una sugerencia para la puerta de enlace, no una exigencia sobre ella.

El fragmento swanctl y dónde va

El ajuste se encuentra dentro del bloque de conexión, no en su propio archivo ni en un perfil del sistema operativo. Este fragmento aislado muestra la forma:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Cárgalo con el archivo que posee la conexión, después inicia la conexión y lee el resultado. Un fragmento pegado en la sección equivocada produce un error de análisis o, peor, una conexión que se carga sin la petición que creías haber hecho. Ejecuta los tres comandos en orden y conserva la salida.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts elige tráfico, no crea una dirección

local_ts nombra el conjunto de tráfico que protege la SA hija; no pone una dirección en una interfaz. Una vez negociada una IP virtual, strongSwan deja de usar su selector dinámico predeterminado y usa en su lugar la dirección concedida. Si fijas el selector a una dirección literal, estás afirmando algo que la puerta de enlace quizá no concedió, y por eso el fallo aparece como una SA que funciona con tráfico que no va a ninguna parte. El selector describe tráfico, mientras que la asignación viene del otro intercambio.

La otra forma de obtener una dirección interna estable es poseerla localmente. Pon la dirección en una interfaz antes de que suba el túnel, apunta el selector a lo que ya existe y organiza el par y la ruta alrededor de eso.

En ese diseño no se negocia nada, así que nada puede reasignarse, y ese es el intercambio: determinismo a cambio de hacer tú mismo el trabajo de direccionamiento. Es un mecanismo distinto, no una variante de vips, por lo que los dos no deben mezclarse en una sola conexión. Un selector fijado junto a una dirección negociada es una conexión que funciona hasta que la puerta de enlace entrega otra cosa.

Verifica qué asignó realmente el respondedor

Lee el listado de SA para encontrar la dirección que concedió la puerta de enlace y luego confirma que la dirección existe en la interfaz. Si las dos no coinciden, el túnel está levantado y el tráfico no va adonde piensas. Una dirección concedida que nunca llega a la interfaz es el fallo más confuso de esta secuencia, porque cada mitad parece correcta por sí sola.

Mantén cuatro direcciones separadas en tus notas: la dirección interna solicitada, la concedida, la dirección LAN de la máquina y la salida pública que informa un sitio web. Pertenecen a capas distintas y aparecen en lugares distintos. Una guía que registra las cuatro es una que otra persona puede seguir sin preguntar qué dirección querías decir. Vuélvelas a leer tras cada recarga, porque el valor concedido es el único que describe el túnel activo.

Mantén el diseño estático aparte

Si necesitas una dirección interna fija, organiza la reserva en la puerta de enlace y deja la petición del cliente como petición. Mezclar un selector fijado con una dirección negociada da una conexión que funciona hasta que la puerta de enlace asigna algo distinto. Anota la regla de reserva junto a la conexión, porque es la parte que un colega no puede deducir del archivo de configuración. Entonces un cliente nuevo hereda la regla en lugar de redescubrirla.

En el cliente Mac integrado no existe ninguno de estos nombres de opción. Usa la asignación o reserva que ofrezca la puerta de enlace y el perfil que publique el operador, y trata cualquier valor del lado del cliente como una sugerencia hasta que hayas releído la asignación. La reversión consiste en quitar la línea vips y recargar, lo que te devuelve a lo que la puerta de enlace asigna por defecto.