Listar unha conexión na configuración de strongSwan só demostra que se cargou unha definición. Non significa que se contactase co par, que exista unha SA de IKE nin que algún tráfico estea protexido. O daemon trata as definicións e as asociacións vivas como obxectos separados, e a distancia entre eles é unha decisión de deseño deliberada. Saber que obxecto estás inspeccionando converte unha falla vaga nunha seguinte orde concreta.

Cargar non é conectar

Unha conexión cargada é unha declaración do que se poderá negociar despois: enderezos do par, credenciais, propostas e selectores de tráfico. Nada nesa declaración esixe que o daemon teña chamado a ninguén. Unha pasarela pode esperar o outro lado, iniciar no arrinque ou esperar que un tráfico coincidente a esperte. As tres son válidas, e as tres vense idénticas no ficheiro de configuración ata que les a política de inicio.

Os operadores métense en problemas ao ler a lista de definicións como unha lista de estado. O perfil está alí, así que se dá por feito que o túnel está ergueito, e a hora seguinte vaise en depurar rutas para unha asociación que nunca se construíu.

O erro contrario é igual de común. Un perfil ausente manda a xente buscar unha falla de rede cando a configuración nunca se cargou. Nomea o obxecto e despois executa a orde que o observa.

Tres obxectos, tres observacións

strongSwan mantén unha definición cargada, unha SA de IKE e unha SA CHILD. A primeira é configuración, a segunda é unha relación de control autenticada e a terceira é protección negociada para o tráfico seleccionado. Mesmo teñen nomes separados, así que un perfil chamado hq pode posuír un child chamado hq-lan.

A táboa asocia cada capa coa orde que a mostra. Le a fila antes de ler o rexistro.

LayerWhat it containsCommand
DefinitionPeer addresses, credentials, proposals, and traffic selectorsswanctl --list-conns
IKE SAOne authenticated control channel to the peerswanctl --list-sas
CHILD SAKeys and selectors for the traffic being protectedChild rows under the IKE SA

Solicitar o child constrúe primeiro a súa SA de IKE pai cando non existe ningunha. Solicitar só a SA de IKE é outra chamada. Unha canle de control que se autentica ben non garante o child que pediches.

Esa diferenza importa durante unha falla parcial. Unha SA de IKE pode estar sa durante o child falla por un desaxuste de selector ou unha proposta que o par non acepta. Os dous obxectos fallan por motivos distintos, así que merecen observacións separadas.

Escolle a acción de inicio a propósito

En swanctl.conf, o start_action dun child decide o comportamento despois da carga. O valor por defecto none deixa a definición para inicio manual ou uso como respondedor. start márcaa, mentres que trap deixa unha política que negocia en canto aparece tráfico coincidente.

Así que tanto «cargar nunca inicia un túnel» como «cargar sempre inicia un» son falsos. A acción forma parte do perfil e debe coincidir co rol do par. Dúas pasarelas que esperan ambas o outro lado producen silencio, non un túnel.

Con trap, o tráfico ten que coincidir cos selectores, así que un ping non relacionado non espertará nada. Con start, o enderezo do par debe ser utilizábel e ambos os dous lados deben poñerse de acordo en autenticación e propostas. Ningunha das dúas accións substitúe a comprobación desas condicións.

A recuperación é unha política á parte

O arrinque non é un keepalive. A detección de par morto, o peche explícito polo par, a renovación de chaves e o reinicio do proceso son eventos de ciclo de vida distintos con axustes propios. Configura cada un a propósito en vez de esperar que un inicio inicial os cubra todos.

Un túnel que sobe no arrinque e morre unha hora despois é unha cuestión de recuperación. A política de inicio fixo o seu traballo e despois deixou de importar. Mira os axustes de DPD e de renovación de chaves antes de culpar a negociación inicial.

Substituír definicións cargadas é unha operación propia. As políticas de inicio non predeterminadas teñen accións inversas documentadas, e unha recarga é un cambio operativo en vez da suposición de que cada asociación se actualizou no seu sitio. Fai as recargas por etapas, onde unha reconexión sexa aceptábel. Conserva a configuración antiga ata que a nova estea probada.

Comproba que existe antes de depurar o encamiñamento

Executa as tres observacións en orde: definicións cargadas, SA de IKE activas e entradas de child. Cada resposta estreita a seguinte pregunta. Salta un paso e acabarás depurando unha capa que nunca se construíu.

Comeza polo que está cargado e polo que está realmente establecido:

swanctl --list-conns
swanctl --list-sas

Se falta o child mentres o perfil é correcto, iníciao polo nome e observa que pasa. A saída adoita dicir se o pai subiu primeiro.

swanctl --initiate --child hq-lan

Unha SA CHILD activa non é a meta. As regras de reenvío, as rutas e a autorización propia da aplicación aínda teñen que encaixar. O ciclo de vida responde o que se negociou; non pode decidir quen pode usar o servizo.

Artigos relacionados