strongSwan vips: pedir unha dirección virtual a IKEv2

vips solicita unha dirección interna de IKEv2; a pasarela decide que concede. Configura a petición, cárgaa e despois verifica que asignou realmente o respondedor.

O teu cliente IKEv2 pode pedir á pasarela unha dirección interna, e a pasarela decide que devolver. En strongSwan, esa petición é o axuste vips, e segue sendo unha petición mesmo cando escribes nel unha dirección concreta. A guía seguinte configura a petición, cárgaa e le o que volveu, porque eses tres pasos fallan de tres maneiras distintas. Ningún deles se acurta por teclear con máis forza.

Que pide vips e que non pode prometer

vips pertence dentro dunha definición de conexión e pide ao respondedor unha dirección virtual. A guía de direccións virtuais de strongSwan é explícita en que a resposta pode ser outra dirección, ou nada de nada, e esa a frase que a xente salta cando escribe un valor e espera que apareza. A petición segue merecendo a pena, porque o que verificas é a resposta. Trata o axuste como unha instrución para preguntar, non como a configuración do resultado.

Pedir 0.0.0.0 solicita calquera dirección virtual IPv4 dispoñible, o que normalmente é correcto cando o valor exacto non importa. Pedir unha dirección concreta é unha suxestión para a pasarela, non unha esixencia sobre ela.

O fragmento swanctl e onde vai

O axuste está dentro do bloque de conexión, non no seu propio ficheiro nin nun perfil do sistema operativo. Este fragmento illado mostra a 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árgao co ficheiro que posúe a conexión, despois inicia a conexión e le o resultado. Un fragmento pegado na sección equivocada produce un erro de análise ou, peor, unha conexión que se carga sen a petición que crías ter feito. Executa os tres comandos en orde e conserva a saída.

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

local_ts elixe tráfico, non crea unha dirección

local_ts nomea o conxunto de tráfico que protexe a SA filla; non pon unha dirección nunha interface. Unha vez negociada unha IP virtual, strongSwan deixa de usar o seu selector dinámico predeterminado e usa no seu lugar a dirección concedida. Se fixas o selector a unha dirección literal, estás afirmando algo que a pasarela quizais non concedeu, e por iso o fallo aparece como unha SA que funciona con tráfico que non vai a ningures. O selector describe tráfico, mentres que a asignación vén do outro intercambio.

A outra forma de obter unha dirección interna estable é posuíla localmente. Pon a dirección nunha interface antes de que suba o túnel, apunta o selector ao que xa existe e organiza o par e a ruta arredor diso.

Nese deseño non se negocia nada, así que nada pode reasignarse, e ese é o intercambio: determinismo a cambio de facer ti mesmo o traballo de direccionamento. É un mecanismo distinto, non unha variante de vips, polo que os dous non deben mesturarse nunha soa conexión. Un selector fixado xunto a unha dirección negociada é unha conexión que funciona ata que a pasarela entrega outra cousa.

Verifica que asignou realmente o respondedor

Le o listado de SA para atopar a dirección que concedeu a pasarela e despois confirma que a dirección existe na interface. Se as dúas non coinciden, o túnel está levantado e o tráfico non vai onde pensas. Unha dirección concedida que nunca chega á interface é o fallo máis confuso desta secuencia, porque cada metade parece correcta por si soa.

Mantén catro direccións separadas nas túas notas: a dirección interna solicitada, a concedida, a dirección LAN da máquina e a saída pública que informa un sitio web. Pertenecen a capas distintas e aparecen en lugares distintos. Unha guía que rexistra as catro é unha que outra persoa pode seguir sen preguntar que dirección querías dicir. Vólveas ler tras cada recarga, porque o valor concedido é o único que describe o túnel activo.

Mantén o deseño estático á parte

Se necesitas unha dirección interna fixa, organiza a reserva na pasarela e deixa a petición do cliente como petición. Mesturar un selector fixado cunha dirección negociada dá unha conexión que funciona ata que a pasarela asigna algo distinto. Anota a regra de reserva xunto á conexión, porque é a parte que un compañeiro non pode deducir do ficheiro de configuración. Entón un cliente novo herda a regra en lugar de redescubrila.

No cliente Mac integrado non existe ningún destes nomes de opción. Usa a asignación ou reserva que ofreza a pasarela e o perfil que publique o operador, e trata calquera valor do lado do cliente como unha suxestión ata que comprobases a asignación. A reversión consiste en quitar a liña vips e recargar, o que te devolve ao que a pasarela asigna por defecto.

Artigos relacionados