strongSwan EAP: l’identità IKE contro il nome AAA atteso

L’autenticazione EAP su IKEv2 può chiedere a un client di convalidare due nomi di server diversi in un’unica connessione. Il gateway che termina IKE presenta un’identità, e il backend EAP che termina lo scambio TLS interno può presentarne un’altra. In strongSwan vivono in blocchi di configurazione diversi, e mettere un nome nel blocco sbagliato produce un errore che sembra un problema di certificato. È la lettura di quale convalida è fallita che ti dice quale blocco modificare.

Una connessione, due identità di server

La prima identità appartiene allo scambio IKE. Il client compone un indirizzo e si aspetta che il peer dimostri un’identità precisa, di solito il nome nel certificato del gateway.

La seconda appartiene a EAP. Con PEAP o TTLS, il client costruisce un tunnel TLS verso il server di autenticazione dentro la IKE SA, e quel server interno presenta il proprio certificato. Quando il backend è un host separato, il suo nome differisce da quello del gateway. Un client che controlla solo il primo nome accetta ciò che afferma il secondo. E un client configurato con un solo nome in entrambi i punti fallisce non appena i due differiscono davvero.

Entrambi i nomi vengono dalla configurazione dell’operatore, non dal certificato che fa sparire l’errore. Chiedere all’operatore i dettagli della distribuzione è più rapido che indovinare due nomi host.

Quale campo appartiene a quale livello

In swanctl l’indirizzo e l’identità IKE sono impostazioni separate, e l’identità EAP è una terza.

L’indirizzo remoto sceglie dove vanno i pacchetti, e l’identità remota indica cosa il peer deve dimostrare. L’attesa EAP si scrive sotto il blocco local, perché descrive lo scambio EAP di questo client e non il comportamento IKE del peer. È proprio questa collocazione a essere letta male. Il nome sta nella configurazione del client mentre descrive un server, ed è esattamente per questo che sembra fuori posto.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Quel frammento non è una connessione completa; materiale di fiducia, credenziali e criteri delle connessioni figlie devono ancora essere presenti. Copiarlo alla lettera in un file di lavoro sostituirebbe impostazioni che servono ancora.

Perché aaa_id vive sotto local

Il blocco local descrive che cosa fa questo estremo durante l’autenticazione, incluso il metodo che userà e l’identità che si aspetta dall’altro estremo per quel metodo. Nulla in esso afferma che il server AAA giri sulla stessa macchina.

Il valore predefinito rende la trappola più affilata. Quando non è impostato un valore esplicito, l’identità AAA attesa segue l’identità remota, così una distribuzione con un solo nome funziona e nasconde la distinzione. Un valore esplicito conta solo quando la distribuzione EAP termina davvero altrove. Impostarlo su un nome diverso senza quel motivo crea un errore che l’operatore non può riprodurre. Leggi la distribuzione prima di inventare un secondo nome.

Mantieni il valore identico a ciò che il certificato del backend afferma davvero, compresa la forma del nome. Un punto finale o un carattere jolly che non copre l’host basta a far fallire il controllo.

Interfacce che non riescono a esprimere la separazione

Un profilo NetworkManager non è la stessa interfaccia di configurazione di swanctl. Il plugin dietro espone un insieme più ristretto di controlli sull’identità, e quali esistano dipende dalla versione installata.

Questo conta quando la distribuzione ha davvero bisogno di due nomi. Un campo etichettato come identità del server può configurare un livello e non l’altro, così un profilo può sembrare corretto e fallire comunque il controllo interno. Verifica cosa supporta il plugin installato prima di supporre che il profilo possa esprimere questa disposizione. Se non può, la scelta spetta all’operatore: un percorso di provisioning diverso o una progettazione corretta dell’identità del server. Indebolire PEAP o accettare qualsiasi nome cambia la politica di autenticazione invece di correggerla.

L’alternativa non è qualcosa da inventare sul client. Chiedi per iscritto la disposizione supportata, poi conserva quella risposta con il profilo.

Distingui una discrepanza di identità da un certificato scaduto

Una discrepanza di nome e un certificato scaduto sono errori diversi, e il registro li distingue. Leggi il messaggio prima di decidere quale campo cambiare.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Impostare l’identità AAA prevista non rinnova un certificato né stabilisce fiducia nel suo emittente, e rinnovare un certificato non corregge un nome atteso sbagliato. Leggi quale convalida è fallita prima di modificare un altro campo di identità. Poi ricarica la configurazione e conferma che la connessione caricata mostri il valore impostato, perché un file modificato che non è mai stato caricato non cambia nulla. Annota entrambi i nomi e i loro livelli nelle note di distribuzione.