strongSwan EAP: IKE-identeco kontraŭ la atendata AAA-nomo

strongSwan EAP-kliento povas validigi du servilajn nomojn. remote.id kovras la IKE-enirejon kaj local.aaa_id la EAP-servilon; ili ne estas unu kampo.

EAP-aŭtentikigo super IKEv2 povas postuli, ke kliento validigu du malsamajn servilajn nomojn en unu konekto. La enirejo, kiu finas IKE, prezentas unu identecon, kaj la EAP-malantaŭo, kiu finas la internan TLS-interŝanĝon, povas prezenti alian. En strongSwan ili loĝas en malsamaj agordaj blokoj, kaj nomo en la malĝusta bloko kaŭzas malsukceson, kiu aspektas kiel atestila problemo. Legi, kiu validigo malsukcesis, estas tio, kio diras al vi, kiun blokon redakti.

Unu konekto, du servilaj identecoj

La unua identeco apartenas al la IKE-interŝanĝo. La kliento vokas adreson kaj atendas, ke la kontraŭanto pruvu apartan identecon, kutime la nomon en la atestilo de la enirejo.

La dua apartenas al EAP. Kun PEAP aŭ TTLS, la kliento konstruas TLS-tunelon al la aŭtentikiga servilo ene de la IKE SA, kaj tiu interna servilo prezentas sian propran atestilon. Kiam la malantaŭo estas aparta gastiganto, ĝia nomo diferencas de tiu de la enirejo. Kliento, kiu kontrolas nur la unuan nomon, akceptas kion ajn la dua asertas. Kaj kliento agordita kun unu nomo en ambaŭ lokoj malsukcesas tuj kiam la du vere diferencas.

Ambaŭ nomoj venas el la agordo de la operatoro, ne el tiu atestilo, kiu forigas la eraron. Demandi la operatoron pri la deploaj detaloj estas pli rapide ol diveni du gastigantajn nomojn.

Kiu kampo apartenas al kiu tavolo

En swanctl la adreso kaj la IKE-identeco estas apartaj agordoj, kaj la EAP-identeco estas tria.

La fora adreso elektas, kien la pakaĵoj iras, kaj la fora identeco diras, kion la kontraŭanto devas pruvi. La EAP-atendo estas skribita sub la bloko local, ĉar ĝi priskribas la EAP-interŝanĝon de ĉi tiu kliento, ne la IKE-konduton de la kontraŭanto. Ĝuste tiu lokado estas mislegata. La nomo staras en la agordo de la kliento dum ĝi priskribas servilon, kaj ĝuste tial ĝi aspektas malĝuste lokita.

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

Tiu fragmento ne estas kompleta konekto; fida materialo, akreditaĵoj kaj politikoj de infanaj konektoj ankoraŭ devas ĉeesti. Kopii ĝin laŭvorte en laboran dosieron anstataŭigus agordojn, kiujn vi ankoraŭ bezonas.

Kial aaa_id loĝas sub local

La bloko local priskribas, kion ĉi tiu flanko faras dum aŭtentikigo, inkluzive la metodon, kiun ĝi uzos, kaj la identecon, kiun ĝi atendas de la alia flanko por tiu metodo. Nenio en ĝi asertas, ke la AAA-servilo funkcias sur la sama maŝino.

La defaŭlto akrigas la kaptilon. Kiam neniu eksplicita valoro estas agordita, la atendata AAA-identeco sekvas la foran identecon, do deploo kun unu nomo funkcias kaj kaŝas la distingon. Eksplicita valoro gravas nur kiam la EAP-deploo vere finiĝas aliloke. Agordi ĝin al alia nomo sen tiu kialo kreas malsukceson, kiun la operatoro ne povas reprodukti. Legu la deploon antaŭ ol elpensi duan nomon.

Tenu la valoron identa al tio, kion la atestilo de la malantaŭo efektive asertas, inkluzive la formon de la nomo. Fina punkto aŭ ĵokera signo, kiu ne kovras la gastiganton, sufiĉas por malsukcesigi la kontrolon.

Fasadoj, kiuj ne povas esprimi la disigon

NetworkManager-profilo ne estas la sama agorda interfaco kiel swanctl. La kromaĵo malantaŭ ĝi montras pli mallarĝan aron de identecaj regiloj, kaj kiuj ekzistas dependas de la instalita versio.

Tio gravas, kiam la deploo vere bezonas du nomojn. Kampo nomita servila identeco povas agordi unu tavolon sed ne la alian, do profilo povas aspekti ĝusta kaj tamen malsukcesi la internan kontrolon. Kontrolu, kion subtenas la instalita kromaĵo, antaŭ ol supozi, ke la profilo povas esprimi tiun aranĝon. Se ĝi ne povas, la elekto apartenas al la operatoro: alia provizvojo aŭ korektita dezajno de la servila identeco. Malfortigi PEAP aŭ akcepti iun ajn nomon ŝanĝas la aŭtentikigan politikon anstataŭ ripari ĝin.

La alternativo ne estas io elpensenda sur la kliento. Petu la subtenatan aranĝon skribe, poste konservu tiun respondon kun la profilo.

Distingi identecan malkongruon disde eksvalidiĝinta atestilo

Noma malkongruo kaj eksvalidiĝinta atestilo estas malsamaj malsukcesoj, kaj la protokolo distingas ilin. Legu la mesaĝon antaŭ ol decidi, kiun kampon ŝanĝi.

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

Agordi la celatan AAA-identecon ne renovigas atestilon nek establas fidon en ĝia eldoninto, kaj renovigi atestilon ne korektas malĝustan atendatan nomon. Legu, kiu validigo malsukcesis, antaŭ ol redakti plian identecan kampon. Poste reŝargu la agordon kaj konfirmu, ke la ŝargita konekto montras la valoron, kiun vi agordis, ĉar redakita dosiero, kiu neniam estis ŝargita, ŝanĝas nenion. Skribu ambaŭ nomojn kaj iliajn tavolojn en la deploajn notojn.

Rilataj artikoloj