strongSwan EAP: IKE-identiteten mot det förväntade AAA-namnet

En strongSwan EAP-klient kan validera två servernamn. remote.id täcker IKE-gatewayen och local.aaa_id täcker EAP-servern; de är inte samma fält.

EAP-autentisering över IKEv2 kan kräva att en klient validerar två olika servernamn i en enda anslutning. Gatewayen som avslutar IKE presenterar en identitet, och EAP-backenden som avslutar det inre TLS-utbytet kan presentera en annan. I strongSwan bor de i olika konfigurationsblock, och ett namn i fel block ger ett fel som ser ut som ett certifikatproblem. Det är läsningen av vilken validering som misslyckades som säger vilket block du ska ändra.

En anslutning, två serveridentiteter

Den första identiteten hör till IKE-utbytet. Klienten ringer en adress och förväntar sig att motparten bevisar en viss identitet, vanligen namnet i gatewayens certifikat.

Den andra hör till EAP. Med PEAP eller TTLS bygger klienten en TLS-tunnel till autentiseringsservern inne i IKE SA, och den inre servern presenterar sitt eget certifikat. När backenden är en separat värd skiljer sig namnet från gatewayens. En klient som bara kontrollerar det första namnet accepterar vad det andra hävdar. Och en klient konfigurerad med ett namn på båda ställena misslyckas så snart de två faktiskt skiljer sig.

Båda namnen kommer från operatörens konfiguration, inte från certifikatet som får felet att försvinna. Att fråga operatören om distributionsdetaljerna är snabbare än att gissa två värdnamn.

Vilket fält hör till vilket lager

I swanctl är adressen och IKE-identiteten separata inställningar, och EAP-identiteten är en tredje.

Fjärradressen väljer vart paketen går, och fjärridentiteten anger vad motparten måste bevisa. EAP-förväntan skrivs under local-blocket, eftersom den beskriver den här klientens EAP-utbyte och inte motpartens IKE-beteende. Det är just den placeringen som läses fel. Namnet står i klientens konfiguration medan det beskriver en server, och därför ser det malplacerat 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 är inte en fullständig anslutning; förtroendematerial, inloggningsuppgifter och policyer för barnanslutningar måste fortfarande finnas. Att kopiera det ordagrant till en fungerande fil skulle ersätta inställningar du fortfarande behöver.

Varför aaa_id bor under local

local-blocket beskriver vad den här änden gör under autentiseringen, inklusive metoden den använder och identiteten den förväntar sig att den andra änden presenterar för den metoden. Ingenting i det påstår att AAA-servern kör på samma maskin.

Standardvärdet gör fällan skarpare. När inget uttryckligt värde är satt följer den förväntade AAA-identiteten fjärridentiteten, så en distribution med ett namn fungerar och döljer skillnaden. Ett uttryckligt värde spelar bara roll när EAP-distributionen verkligen slutar någon annanstans. Att sätta det till ett annat namn utan den anledningen skapar ett fel som operatören inte kan återskapa. Läs distributionen innan du hittar på ett andra namn.

Håll värdet identiskt med vad backend-certifikatet faktiskt hävdar, inklusive namnets form. En avslutande punkt eller ett jokertecken som inte täcker värden räcker för att kontrollen ska misslyckas.

Gränssnitt som inte kan uttrycka uppdelningen

En NetworkManager-profil är inte samma konfigurationsgränssnitt som swanctl. Insticksprogrammet bakom exponerar en snävare uppsättning identitetskontroller, och vilka som finns beror på den installerade versionen.

Det spelar roll när distributionen verkligen behöver två namn. Ett fält märkt serveridentitet kan konfigurera det ena lagret men inte det andra, så en profil kan se korrekt ut och ändå misslyckas i den inre kontrollen. Kontrollera vad det installerade insticksprogrammet stöder innan du antar att profilen kan uttrycka arrangemanget. Om den inte kan det ligger valet hos operatören: en annan etableringsväg eller en korrigerad design av serveridentiteten. Att försvaga PEAP eller acceptera vilket namn som helst ändrar autentiseringspolicyn i stället för att rätta den.

Alternativet är inte något man hittar på på klienten. Begär det stödda arrangemanget skriftligt och behåll sedan svaret tillsammans med profilen.

Skilj en identitetsavvikelse från ett utgånget certifikat

En namnavvikelse och ett utgånget certifikat är olika fel, och loggen skiljer dem. Läs meddelandet innan du bestämmer vilket fält du ska ändra.

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

Att sätta den avsedda AAA-identiteten förnyar inte ett certifikat och etablerar inte förtroende för dess utfärdare, och att förnya ett certifikat rättar inte ett felaktigt förväntat namn. Läs vilken validering som misslyckades innan du ändrar ett annat identitetsfält. Läs sedan in konfigurationen igen och bekräfta att den inlästa anslutningen visar värdet du satte, eftersom en ändrad fil som aldrig lästes in inte ändrar något. Skriv båda namnen och deras lager i distributionsanteckningarna.

Relaterade artiklar