Hvorfor RADIUS ser en IP-adresse i stedet for VPN-brugernavnet

strongSwan kan lægge IKE-identiteten i RADIUS User-Name før nogen EAP-udveksling. Beslut, hvem der anmoder om kontoidentiteten, og korrelér derefter ét forsøg.

En Windows IKEv2-klient opretter forbindelse, og RADIUS-anmodningen ankommer med en adresse, hvor kontonavnet burde være. Intet er fejlet endnu, og det er netop det forvirrende: gatewayen rapporterer den identitet, klienten præsenterede på IKE-laget. Det brugernavn, din backend vil have, kommer måske fra en separat EAP-udveksling, som endnu ikke er sket. Beslut, hvem der spørger efter det, før du ændrer kontoen.

To identiteter rejser i én forbindelse

Der kan optræde to navne i én forbindelse. IKE-identiteten identificerer modparten under tunnelopsætningen, og eap-radius-pluginet kopierer den først til RADIUS User-Name. EAP-identiteten er en anden værdi, der bruges til brugerautentificering, og den sendes måske aldrig, hvis ingen spørger efter den.

Derfor kan RADIUS-loggen vise en adresse, selv om kontoen findes, og adgangskoden er korrekt. Backenden bliver spurgt om det forkerte lag. RADIUS-attributten er kun transporten for det navn, der blev valgt.

Bed gatewayen om at anmode om en EAP-identitet

Én understøttet opsætning lader gatewayen anmode om EAP-identiteten, før autentificeringen overdrages til RADIUS. I forbindelsens afsnit for fjernautentificering sættes metoden til eap-radius, og der anmodes udtrykkeligt om EAP-identiteten. Fragmentet nedenfor hører inde i en eksisterende forbindelsesblok, ikke i sin egen fil. Bekræft forbindelsen og konfigurationsbackenden, før du kopierer syntaks fra en anden udrulning.

remote {
    auth = eap-radius
    eap_id = %any
}

Med det på plads modtager backenden den identitet, klienten angiver i EAP-udvekslingen, i stedet for IKE-adressen. Intet andet ved forbindelsen ændres.

Eller lad RADIUS starte EAP-udvekslingen

Den anden opsætning lægger det første træk på RADIUS-siden. Pluginet kan sende en EAP-Start-indikation i stedet for at vente på et indledende identitetssvar, hvilket lader serveren styre udvekslingen. Det er konfiguration på plugin-niveau, så det påvirker enhver forbindelse, der bruger pluginet.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Vælg én opsætning sammen med RADIUS-operatøren i stedet for at aktivere begge og håbe. De beskriver forskellige arbejdsgange, og en server, der forventer at starte, håndterer ikke nødvendigvis en gateway, der begynder samtalen. Plugin-dokumentationen beskriver begge, inklusive hvilken identitet hvert trin bærer.

Følg ét forsøg gennem begge logs

Korrelér et enkelt forsøg på tværs af begge logs. Se på IKE-identiteten, derefter om der sker en EAP-Identity-udveksling, og derefter hvilket navn autentificeringstrinnet modtager. En backend, der afviser adressen før EAP-udvekslingen, kan stoppe processen, før din tilsigtede identitet nogensinde ses.

journalctl -u strongswan -f

Behold det præcise brugernavnsformat, identitetssystemet forventer, inklusive domænepræfikset. Opfind aldrig en konto ud fra en adresselignende værdi, og slå aldrig autentificering fra for at opfylde en politikregel. En EAP-identitet er et erklæret navn, og metoden skal stadig bevise det. Skriv det resulterende navn i testprotokollen, så det næste forsøg starter fra en kendt tilstand.

Hvis det rettede flow når den rigtige konto og stadig afvises, er det næste bevis EAP-metoden og backend-politikken, ikke identiteten. Gentagen nulstilling af adgangskoden kan ikke reparere en værdi, der blev valgt på et tidligere protokollag.

Relaterede artikler