strongSwan EAP: la identitat IKE enfront del nom AAA esperat

L’autenticació EAP sobre IKEv2 pot demanar a un client que validi dos noms de servidor diferents en una sola connexió. La passarel·la que acaba IKE presenta una identitat, i el rerefons EAP que acaba l’intercanvi TLS intern en pot presentar una altra. A strongSwan viuen en blocs de configuració diferents, i posar un nom al bloc equivocat produeix un error que sembla un problema de certificat. Llegir quina validació ha fallat és el que et diu quin bloc cal editar.

Una connexió, dues identitats de servidor

La primera identitat pertany a l’intercanvi IKE. El client marca una adreça i espera que l’altre extrem demostri una identitat concreta, normalment el nom del certificat de la passarel·la.

La segona pertany a EAP. Amb PEAP o TTLS, el client construeix un túnel TLS cap al servidor d’autenticació dins de la IKE SA, i aquest servidor intern presenta el seu propi certificat. Quan el rerefons és un host separat, el seu nom difereix del de la passarel·la. Un client que només comprova el primer nom accepta el que afirmi el segon. I un client configurat amb un sol nom als dos llocs falla tan bon punt els dos divergeixen de veritat.

Tots dos noms vénen de la configuració de l’operador, no del certificat que fa desaparèixer l’error. Demanar a l’operador els detalls del desplegament és més ràpid que endevinar dos noms d’host.

Quin camp pertany a quina capa

A swanctl, l’adreça i la identitat IKE són paràmetres separats, i la identitat EAP és un tercer.

L’adreça remota tria on van els paquets, i la identitat remota indica què ha de demostrar l’altre extrem. L’expectativa EAP s’escriu sota el bloc local, perquè descriu l’intercanvi EAP d’aquest client i no el comportament IKE de l’altre extrem. Aquesta ubicació és la part que la gent llegeix malament. El nom se situa a la configuració del client mentre descriu un servidor, i per això mateix sembla fora de lloc.

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

Aquest fragment no és una connexió completa; encara hi han de ser el material de confiança, les credencials i les polítiques de les connexions filles. Copiar-lo literalment en un fitxer de treball substituiria paràmetres que encara necessites.

Per què aaa_id viu sota local

El bloc local descriu què fa aquest extrem durant l’autenticació, incloent-hi el mètode que farà servir i la identitat que espera que l’altre extrem presenti per a aquest mètode. Res no hi afirma que el servidor AAA s’executi a la mateixa màquina.

El valor per defecte fa la trampa més afilada. Quan no es fixa cap valor explícit, la identitat AAA esperada segueix la identitat remota, així que un desplegament amb un sol nom funciona i amaga la distinció. Un valor explícit només importa quan el desplegament EAP acaba realment en un altre lloc. Fixar-lo a un nom diferent sense aquest motiu crea un error que l’operador no pot reproduir. Llegeix el desplegament abans d’inventar un segon nom.

Mantingues el valor idèntic al que afirma realment el certificat del rerefons, inclosa la forma del nom. Un punt final o un comodí que no cobreixi l’host ja n’hi ha prou per fer fallar la comprovació.

Interfícies que no poden expressar la separació

Un perfil de NetworkManager no és la mateixa interfície de configuració que swanctl. El connector que hi ha al darrere exposa un conjunt més estret de controls d’identitat, i quins existeixen depèn de la versió instal·lada.

Això importa quan el desplegament necessita de veritat dos noms. Un camp etiquetat com a identitat del servidor pot configurar una capa i no l’altra, així que un perfil pot semblar correcte i fallar igualment la comprovació interna. Comprova què admet el connector instal·lat abans de suposar que el perfil pot expressar aquesta disposició. Si no pot, l’elecció és de l’operador: una via de subministrament diferent o un disseny corregit de la identitat del servidor. Debilitar PEAP o acceptar qualsevol nom canvia la política d’autenticació en lloc d’arreglar-la.

L’alternativa no és una cosa per inventar al client. Demana la disposició admesa per escrit i després guarda aquesta resposta amb el perfil.

Distingeix una discrepància d’identitat d’un certificat caducat

Una discrepància de nom i un certificat caducat són errors diferents, i el registre els distingeix. Llegeix el missatge abans de decidir quin camp canviar.

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

Fixar la identitat AAA prevista no renova cap certificat ni estableix confiança en el seu emissor, i renovar un certificat no corregeix un nom esperat equivocat. Llegeix quina validació ha fallat abans d’editar un altre camp d’identitat. Després recarrega la configuració i confirma que la connexió carregada mostra el valor que has fixat, perquè un fitxer editat que mai no s’ha carregat no canvia res. Escriu tots dos noms i les seves capes a les notes del desplegament.