ipsec.conf o swanctl.conf? Scegliete un frontend strongSwan

Un profilo IKEv1 funzionante, preso da una guida più vecchia, arriva su Ubuntu 24.04, e il primo tentativo fallisce perché il demone non ha mai letto il file. La reazione abituale è modificare di nuovo il profilo. La domanda vera è quale frontend strongSwan sia installato e quale usi il servizio in esecuzione. Finché non si risponde, ogni modifica punta a un caricatore che forse non esiste.

Due file, due caricatori, un demone

Il vecchio schema starter legge ipsec.conf e consegna le connessioni a charon tramite la sua vecchia integrazione di gestione. Il suo punto di ingresso operativo è il comando ipsec.

Lo schema swanctl carica le definizioni tramite VICI, legge swanctl.conf ed è guidato dal comando swanctl. Il demone charon nativo di systemd si integra con questo approccio.

Entrambi possono essere installati sulla stessa macchina, ed è lì che inizia la confusione. Un file sotto /etc dimostra solo che qualcuno lo ha scritto, non che il processo in esecuzione lo abbia caricato. Installare tutte le alternative per vedere quale funziona crea un host con due percorsi di gestione e senza un proprietario chiaro. Scegliete uno schema e rimuovete o disabilitate l’altro.

Leggete i pacchetti e le unità installati

Cominciate in sola lettura. I nomi dei pacchetti su Ubuntu 24.04 sono separati: strongswan-starter, strongswan-swanctl e charon-systemd. Un pacchetto mancante è un’informazione utile, non un’istruzione a installarlo.

Inventariate i pacchetti e le unità in un solo passaggio:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Poi ispezionate l’unità attiva e il suo comando di avvio. Il nome dell’unità dice quale demone possiede la configurazione, e la riga di comando conferma quali file gli è stato chiesto di leggere. Un’unità abilitata ma inattiva racconta una storia diversa da quella in esecuzione ora.

Se l’unità attiva è strongswan-starter, il file che conta è ipsec.conf. Se è charon-systemd con swanctl, ipsec.conf è solo decorazione.

Usate il percorso di controllo corrispondente

Ogni frontend ha la propria visione delle connessioni e delle associazioni. swanctl --list-conns mostra le definizioni caricate e swanctl --list-sas mostra le associazioni attive. Il percorso vecchio usa ipsec statusall.

Mescolarli produce errori ingannevoli. Un socket VICI mancante o una richiesta di controllo rifiutata è un problema del percorso di gestione, non la prova che il peer abbia rifiutato l’autenticazione.

Leggete la visione che appartiene al demone in esecuzione, poi interpretate il risultato. Se la connessione manca da quella visione, il problema è il caricamento, non la negoziazione.

Il formato non è la versione IKE

Un profilo vecchio seleziona IKEv1 con keyexchange=ikev1. Una connessione swanctl usa un’impostazione di versione, dove 1 seleziona IKEv1. Sono due vocabolari per la stessa idea, non una conversione.

Gli indirizzi del peer, le identità locale e remota, le fonti delle credenziali, le proposte e i selettori child vanno mappati di proposito. Incollare un blocco left/right nella sintassi swanctl non fa nulla di tutto questo.

Cambiare solo la versione del protocollo è la mezza migrazione più comune. Produce un file che si carica e poi fallisce l’autenticazione per motivi estranei alla versione. IKEv1 stesso è deprecato dal RFC 9395, quindi un peer esistente che lo richiede ancora merita un vincolo di compatibilità documentato e un percorso di migrazione, non un nuovo valore predefinito.

Controllate il caricatore prima di toccare il profilo

Eseguite prima il controllo del caricatore, poi caricate la connessione voluta, poi valutate la negoziazione e infine il percorso del traffico protetto. Ogni fase ha una firma di errore diversa.

I due percorsi di controllo rispondono direttamente alla domanda sul caricamento:

swanctl --list-conns
ipsec statusall

Solo uno di questi comandi appartiene al vostro host. Eseguire entrambi e confrontare l’output è un modo per scoprire quale vi mente, non un metodo diagnostico.

Trattate la proprietà dei pacchetti, il caricamento della configurazione e la compatibilità del protocollo come tre domande separate. Un file valido per un frontend verrà altrimenti modificato ancora e ancora mentre un altro demone è quello in esecuzione.