EAP-autentisering over IKEv2 kan krevje at ein klient validerer to ulike servernamn i éi tilkopling. Gatewayen som avsluttar IKE, presenterer éin identitet, og EAP-backenden som avsluttar den indre TLS-utvekslinga kan presentere ein annan. I strongSwan bur dei i ulike konfigurasjonsblokker, og eit namn i feil blokk gjev ein feil som ser ut som eit sertifikatproblem. Det er lesinga av kva validering som feila som fortel deg kva blokk du skal endre.

Éi tilkopling, to serveridentitetar

Den første identiteten høyrer til IKE-utvekslinga. Klienten ringjer ein adresse og ventar at motparten beviser ein bestemt identitet, vanlegvis namnet i gatewayen sitt sertifikat.

Den andre høyrer til EAP. Med PEAP eller TTLS byggjer klienten ein TLS-tunnel til autentiseringsserveren inne i IKE SA, og den indre serveren presenterer sitt eige sertifikat. Når backenden er ein eigen vert, avvik namnet frå gatewayen sitt. Ein klient som berre kontrollerer det første namnet, godtek det den andre påstår. Og ein klient sett opp med eitt namn begge stader feilar så snart dei to faktisk avvik.

Begge namna kjem frå konfigurasjonen til operatøren, ikkje frå sertifikatet som får feilen til å forsvinne. Å spørje operatøren om distribusjonsdetaljane er raskare enn å gjette på to vertsnamn.

Kva felt høyrer til kva lag

I swanctl er adressa og IKE-identiteten separate innstillingar, og EAP-identiteten er ein tredje.

Fjernadressa vel kvar pakkane går, og fjernidentiteten seier kva motparten må bevisa. EAP-forventninga blir skriven under local-blokka, fordi ho skildrar EAP-utvekslinga til denne klienten og ikkje IKE-åtferda til motparten. Det er nettopp denne plasseringa folk les feil. Namnet står i konfigurasjonen til klienten medan det skildrar ein server, og difor ser det malplassert ut.

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

Det utdraget er ikkje ei fullstendig tilkopling; tillitsmateriale, påloggingsinformasjon og retningslinjer for barnetilkoplingar må framleis vere til stades. Å kopiere det ordrett inn i ei fungerande fil ville erstatte innstillingar du framleis treng.

Kvifor aaa_id bur under local

local-blokka skildrar kva denne enden gjer under autentiseringa, inkludert metoden han vil bruke og identiteten han ventar at den andre enden presenterer for den metoden. Ingenting i ho påstår at AAA-serveren køyrer på same maskin.

Standardverdien gjer fella skarpare. Når ingen eksplisitt verdi er sett, følgjer den forventa AAA-identiteten fjernidentiteten, slik at ein distribusjon med eitt namn fungerer og skjuler skilnaden. Ein eksplisitt verdi betyr berre noko når EAP-distribusjonen faktisk avsluttar ein annan stad. Å setje han til eit anna namn utan den grunnen skapar ein feil operatøren ikkje kan gjenskape. Les distribusjonen før du finn opp eit andre namn.

Hald verdien identisk med det backend-sertifikatet faktisk påstår, inkludert forma på namnet. Ein avsluttande prikk eller eit jokerteikn som ikkje dekkjer verten er nok til at kontrollen feilar.

Grensesnitt som ikkje kan uttrykkje oppdelinga

Ein NetworkManager-profil er ikkje det same konfigurasjonsgrensesnittet som swanctl. Programtillegget bak han eksponerer eit smalare sett med identitetskontrollar, og kva for nokre som finst avheng av den installerte versjonen.

Det betyr noko når distribusjonen verkeleg treng to namn. Eit felt merkt serveridentitet kan konfigurere det eine laget og ikkje det andre, slik at ein profil kan sjå rett ut og likevel feile den indre kontrollen. Sjekk kva det installerte programtillegget støttar før du går ut frå at profilen kan uttrykkje ordninga. Kan han ikkje det, høyrer valet til operatøren: ein annan klargjeringsveg eller eit korrigert design av serveridentiteten. Å svekkje PEAP eller godta eit kva som helst namn endrar autentiseringspolitikken i staden for å rette han.

Alternativet er ikkje noko ein finn opp på klienten. Be om den støtta ordninga skriftleg, og ta vare på svaret saman med profilen.

Skil identitetsavvik frå eit utløpt sertifikat

Eit namneavvik og eit utløpt sertifikat er ulike feil, og loggen skil dei. Les meldinga før du bestemmer kva felt du skal endre.

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

Å setje den tiltenkte AAA-identiteten fornyar ikkje eit sertifikat eller etablerer tillit til utferdaren, og å fornye eit sertifikat rettar ikkje eit feil forventa namn. Les kva validering som feila før du endrar eit anna identitetsfelt. Last deretter konfigurasjonen på nytt og stadfest at den lasta tilkoplinga viser verdien du sette, for ei endra fil som aldri blei lasta, endrar ingenting. Skriv begge namna og laga deira i distribusjonsnotata.

Relaterte artiklar