strongSwan EAP: IKE-identitet kontra det forventede AAA-navn

EAP-godkendelse over IKEv2 kan kræve, at en klient validerer to forskellige servernavne i én forbindelse. Gatewayen, der afslutter IKE, fremviser én identitet, og EAP-backenden, der afslutter den indre TLS-udveksling, kan fremvise en anden. I strongSwan bor de i forskellige konfigurationsblokke, og et navn i den forkerte blok giver en fejl, der ligner et certifikatproblem. Det er læsningen af, hvilken validering der fejlede, der fortæller dig, hvilken blok du skal rette.

Én forbindelse, to serveridentiteter

Den første identitet hører til IKE-udvekslingen. Klienten ringer til en adresse og forventer, at modparten beviser en bestemt identitet, som regel navnet i gatewayens certifikat.

Den anden hører til EAP. Med PEAP eller TTLS bygger klienten en TLS-tunnel til godkendelsesserveren inde i IKE SA, og den indre server fremviser sit eget certifikat. Når backenden er en separat vært, afviger dens navn fra gatewayens. En klient, der kun kontrollerer det første navn, accepterer, hvad det andet påstår. Og en klient konfigureret med ét navn begge steder fejler, så snart de to faktisk afviger.

Begge navne kommer fra operatørens konfiguration og ikke fra det certifikat, der får fejlen til at forsvinde. At spørge operatøren om udrulningsdetaljerne er hurtigere end at gætte på to værtsnavne.

Hvilket felt hører til hvilket lag

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

Fjernadressen vælger, hvor pakkerne går hen, og fjernidentiteten angiver, hvad modparten skal bevise. EAP-forventningen skrives under local-blokken, fordi den beskriver denne klients EAP-udveksling frem for modpartens IKE-adfærd. Det er netop den placering, folk læser forkert. Navnet står i klientens konfiguration, mens det beskriver en server, og derfor ser det malplaceret ud.

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

Det uddrag er ikke en fuld forbindelse; tillidsmateriale, legitimationsoplysninger og politikker for underordnede forbindelser skal stadig være til stede. At kopiere det ordret ind i en fungerende fil ville erstatte indstillinger, du stadig har brug for.

Hvorfor aaa_id bor under local

local-blokken beskriver, hvad denne ende gør under godkendelsen, inklusive den metode, den vil bruge, og den identitet, den forventer, at den anden ende fremviser for den metode. Intet i den påstår, at AAA-serveren kører på samme maskine.

Standardværdien gør fælden skarpere. Når ingen udtrykkelig værdi er sat, følger den forventede AAA-identitet fjernidentiteten, så en udrulning med ét navn virker og skjuler forskellen. En udtrykkelig værdi betyder kun noget, når EAP-udrulningen virkelig afsluttes et andet sted. At sætte den til et andet navn uden den grund skaber en fejl, som operatøren ikke kan genskabe. Læs udrulningen, før du opfinder et andet navn.

Hold værdien identisk med det, backend-certifikatet faktisk påstår, inklusive navnets form. En afsluttende prik eller et jokertegn, der ikke dækker værten, er nok til at kontrollen fejler.

Frontends, der ikke kan udtrykke opdelingen

En NetworkManager-profil er ikke den samme konfigurationsflade som swanctl. Pluginnet bag den udstiller et snævrere sæt identitetskontroller, og hvilke der findes afhænger af den installerede version.

Det betyder noget, når udrulningen virkelig har brug for to navne. Et felt mærket serveridentitet kan konfigurere det ene lag og ikke det andet, så en profil kan se korrekt ud og alligevel fejle den indre kontrol. Undersøg, hvad det installerede plugin understøtter, før du antager, at profilen kan udtrykke arrangementet. Hvis den ikke kan, hører valget til operatøren: en anden klargøringskanal eller et korrigeret design af serveridentiteten. At svække PEAP eller acceptere et vilkårligt navn ændrer godkendelsespolitikken i stedet for at rette den.

Alternativet er ikke noget, man opfinder på klienten. Bed om det understøttede arrangement skriftligt, og opbevar derefter svaret sammen med profilen.

Skeln identitetsuoverensstemmelse fra et udløbet certifikat

En navneuoverensstemmelse og et udløbet certifikat er forskellige fejl, og loggen skelner mellem dem. Læs meddelelsen, før du beslutter, hvilket felt der skal ændres.

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

At sætte den tilsigtede AAA-identitet fornyer ikke et certifikat eller etablerer tillid til dets udsteder, og at forny et certifikat retter ikke et forkert forventet navn. Læs, hvilken validering der fejlede, før du retter endnu et identitetsfelt. Genindlæs derefter konfigurationen, og bekræft at den indlæste forbindelse viser den værdi, du satte, for en rettet fil, der aldrig blev indlæst, ændrer intet. Skriv begge navne og deres lag i udrulningsnotaterne.