Un perfil de strongSwan cargado non é un túnel activo
strongSwan carga definicións e despois negocia as SA de IKE e CHILD. Que un perfil estea cargado non di nada sobre se existe un túnel nin sobre quen o inicia.
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.
| Layer | What it contains | Command |
|---|---|---|
| Definition | Peer addresses, credentials, proposals, and traffic selectors | swanctl --list-conns |
| IKE SA | One authenticated control channel to the peer | swanctl --list-sas |
| CHILD SA | Keys and selectors for the traffic being protected | Child 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.