strongSwan EAP: a identidade IKE fronte ao nome AAA esperado

Un cliente strongSwan EAP pode validar dous nomes de servidor. remote.id cobre a pasarela IKE e local.aaa_id cobre o servidor EAP; non son un só campo.

A autenticación EAP sobre IKEv2 pode pedir a un cliente que valide dous nomes de servidor distintos nunha soa conexión. A pasarela que remata IKE presenta unha identidade, e o backend EAP que remata o intercambio TLS interno pode presentar outra. En strongSwan viven en bloques de configuración distintos, e pór un nome no bloque equivocado produce un fallo que parece un problema de certificado. Ler que validación fallou é o que che di que bloque editar.

Unha conexión, dúas identidades de servidor

A primeira identidade pertence ao intercambio IKE. O cliente marca un enderezo e espera que o par demostre unha identidade concreta, normalmente o nome do certificado da pasarela.

A segunda pertence a EAP. Con PEAP ou TTLS, o cliente constrúe un túnel TLS cara ao servidor de autenticación dentro da IKE SA, e ese servidor interno presenta o seu propio certificado. Cando o backend é un host aparte, o seu nome difire do da pasarela. Un cliente que só comproba o primeiro nome acepta o que afirme o segundo. E un cliente configurado cun só nome nos dous sitios falla en canto os dous difiren de verdade.

Ambos os nomes veñen da configuración do operador, non do certificado que fai desaparecer o erro. Preguntar ao operador polos detalles do despregamento é máis rápido que adiviñar dous nomes de host.

Que campo pertence a que capa

En swanctl, o enderezo e a identidade IKE son axustes separados, e a identidade EAP é un terceiro.

O enderezo remoto escolle a onde van os paquetes, e a identidade remota indica que debe demostrar o par. A expectativa EAP escríbese baixo o bloque local, porque describe o intercambio EAP deste cliente e non o comportamento IKE do par. Ese emprazamento é a parte que a xente le mal. O nome está na configuración do cliente mentres describe un servidor, e por iso mesmo parece fóra de lugar.

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

Ese fragmento non é unha conexión completa; o material de confianza, as credenciais e as políticas das conexións fillas aínda deben estar presentes. Copialo tal cal nun ficheiro de traballo substituiría axustes que aínda necesitas.

Por que aaa_id vive baixo local

O bloque local describe que fai este extremo durante a autenticación, incluído o método que usará e a identidade que espera que o outro extremo presente para ese método. Nada nel afirma que o servidor AAA se execute na mesma máquina.

O valor predeterminado agudiza a trampa. Cando non se fixa un valor explícito, a identidade AAA esperada segue a identidade remota, así que un despregamento cun só nome funciona e oculta a distinción. Un valor explícito só importa cando o despregamento EAP remata de verdade noutro sitio. Fixalo a un nome distinto sen ese motivo crea un fallo que o operador non pode reproducir. Le o despregamento antes de inventar un segundo nome.

Mantén o valor idéntico ao que afirma realmente o certificado do backend, incluída a forma do nome. Un punto final ou un comodín que non cubra o host abonda para que a comprobación falle.

Interfaces que non poden expresar a separación

Un perfil de NetworkManager non é a mesma interface de configuración que swanctl. O complemento que hai detrás expón un conxunto máis estreito de controis de identidade, e cales existen depende da versión instalada.

Iso importa cando o despregamento necesita de verdade dous nomes. Un campo etiquetado como identidade do servidor pode configurar unha capa e non a outra, así que un perfil pode parecer correcto e aínda así fallar a comprobación interna. Comproba que admite o complemento instalado antes de supoñer que o perfil pode expresar esa disposición. Se non pode, a elección é do operador: unha vía de aprovisionamento distinta ou un deseño corrixido da identidade do servidor. Debilitar PEAP ou aceptar calquera nome cambia a política de autenticación en lugar de arranxala.

A alternativa non é algo que inventar no cliente. Pide por escrito a disposición admitida e despois garda esa resposta co perfil.

Distingue unha discrepancia de identidade dun certificado caducado

Unha discrepancia de nome e un certificado caducado son fallos distintos, e o rexistro distíngueos. Le a mensaxe antes de decidir que campo cambiar.

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

Fixar a identidade AAA prevista non renova un certificado nin establece confianza no seu emisor, e renovar un certificado non corrixe un nome esperado equivocado. Le que validación fallou antes de editar outro campo de identidade. Despois recarga a configuración e confirma que a conexión cargada mostra o valor que fixaches, porque un ficheiro editado que nunca se cargou non cambia nada. Escribe ambos os nomes e as súas capas nas notas do despregamento.

Artigos relacionados