strongSwan EAP: IKE-identitet mot det forventede AAA-navnet

EAP-autentisering over IKEv2 kan kreve at en klient validerer to forskjellige servernavn i én tilkobling. Gatewayen som avslutter IKE, presenterer én identitet, og EAP-backenden som avslutter den indre TLS-utvekslingen kan presentere en annen. I strongSwan bor de i forskjellige konfigurasjonsblokker, og et navn i feil blokk gir en feil som ser ut som et sertifikatproblem. Det er lesingen av hvilken validering som feilet som forteller deg hvilken blokk du skal endre.

Én tilkobling, to serveridentiteter

Den første identiteten hører til IKE-utvekslingen. Klienten ringer en adresse og forventer at motparten beviser en bestemt identitet, vanligvis navnet i gatewayens sertifikat.

Den andre hører til EAP. Med PEAP eller TTLS bygger klienten en TLS-tunnel til autentiseringsserveren inne i IKE SA, og den indre serveren presenterer sitt eget sertifikat. Når backenden er en egen vert, avviker navnet fra gatewayens. En klient som bare kontrollerer det første navnet, godtar det den andre påstår. Og en klient konfigurert med ett navn begge steder feiler så snart de to faktisk avviker.

Begge navnene kommer fra operatørens konfigurasjon, ikke fra sertifikatet som får feilen til å forsvinne. Å spørre operatøren om distribusjonsdetaljene er raskere enn å gjette på to vertsnavn.

Hvilket felt hører til hvilket lag

I swanctl er adressen og IKE-identiteten separate innstillinger, og EAP-identiteten er en tredje.

Fjernadressen velger hvor pakkene går, og fjernidentiteten angir hva motparten må bevise. EAP-forventningen skrives under local-blokken, fordi den beskriver denne klientens EAP-utveksling og ikke motpartens IKE-atferd. Det er nettopp denne plasseringen folk leser feil. Navnet står i klientens konfigurasjon mens det beskriver en server, og derfor 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 ikke en fullstendig tilkobling; tillitsmateriale, påloggingsinformasjon og retningslinjer for barntilkoblinger må fortsatt være til stede. Å kopiere det ordrett inn i en fungerende fil ville erstatte innstillinger du fortsatt trenger.

Hvorfor aaa_id bor under local

local-blokken beskriver hva denne enden gjør under autentiseringen, inkludert metoden den vil bruke og identiteten den forventer at den andre enden presenterer for den metoden. Ingenting i den påstår at AAA-serveren kjører på samme maskin.

Standardverdien gjør fellen skarpere. Når ingen eksplisitt verdi er satt, følger den forventede AAA-identiteten fjernidentiteten, slik at en distribusjon med ett navn fungerer og skjuler forskjellen. En eksplisitt verdi betyr bare noe når EAP-distribusjonen faktisk avsluttes et annet sted. Å sette den til et annet navn uten den grunnen skaper en feil operatøren ikke kan gjenskape. Les distribusjonen før du finner opp et andre navn.

Hold verdien identisk med det backend-sertifikatet faktisk påstår, inkludert navnets form. En avsluttende prikk eller et jokertegn som ikke dekker verten er nok til at kontrollen feiler.

Grensesnitt som ikke kan uttrykke oppdelingen

En NetworkManager-profil er ikke det samme konfigurasjonsgrensesnittet som swanctl. Programtillegget bak den eksponerer et smalere sett med identitetskontroller, og hvilke som finnes avhenger av den installerte versjonen.

Det betyr noe når distribusjonen virkelig trenger to navn. Et felt merket serveridentitet kan konfigurere det ene laget og ikke det andre, slik at en profil kan se riktig ut og likevel feile den indre kontrollen. Sjekk hva det installerte programtillegget støtter før du antar at profilen kan uttrykke ordningen. Hvis den ikke kan, hører valget til operatøren: en annen klargjøringsvei eller et korrigert design av serveridentiteten. Å svekke PEAP eller godta et hvilket som helst navn endrer autentiseringspolicyen i stedet for å rette den.

Alternativet er ikke noe man finner opp på klienten. Be om den støttede ordningen skriftlig, og ta vare på svaret sammen med profilen.

Skill identitetsavvik fra et utløpt sertifikat

Et navneavvik og et utløpt sertifikat er forskjellige feil, og loggen skiller dem. Les meldingen før du bestemmer hvilket felt du skal endre.

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

Å sette den tiltenkte AAA-identiteten fornyer ikke et sertifikat eller etablerer tillit til utstederen, og å fornye et sertifikat retter ikke et feil forventet navn. Les hvilken validering som feilet før du endrer et annet identitetsfelt. Last deretter konfigurasjonen på nytt og bekreft at den lastede tilkoblingen viser verdien du satte, for en endret fil som aldri ble lastet, endrer ingenting. Skriv begge navnene og lagene deres i distribusjonsnotatene.