Waarom RADIUS 'n IP-adres eerder as die VPN-gebruikersnaam sien

strongSwan kan die IKE-identiteit in die RADIUS User-Name plaas voordat enige EAP-uitruiling plaasvind. Besluit wie om die rekeningidentiteit vra, en korreleer dan een poging.

'n Windows IKEv2-kliënt maak verbinding, en die RADIUS-versoek kom aan met 'n adres waar die rekeningnaam behoort te wees. Niks het nog misluk nie, en dit is juis die verwarrende deel: die poort rapporteer die identiteit wat die kliënt op die IKE-laag aangebied het. Die gebruikersnaam wat jou backend wil hê, kom moontlik uit 'n aparte EAP-uitruiling wat nog nie plaasgevind het nie. Besluit wie daarvoor vra voordat jy die rekening verander.

Twee identiteite reis in een verbinding

Twee name kan in een verbinding voorkom. Die IKE-identiteit identifiseer die eweknie tydens tonnelopstelling, en die eap-radius-inprop kopieer dit aanvanklik na RADIUS User-Name. Die EAP-identiteit is 'n ander waarde, wat vir gebruikersverifikasie gebruik word, en dit word dalk nooit gestuur as niemand daarvoor vra nie.

Daarom kan die RADIUS-log 'n adres wys terwyl die rekening bestaan en die wagwoord korrek is. Die backend word oor die verkeerde laag gevra. Die RADIUS-kenmerk is net die vervoer vir watter naam ook al gekies is.

Vra die poort om 'n EAP-identiteit aan te vra

Een ondersteunde reëling laat die poort die EAP-identiteit aanvra voordat verifikasie aan RADIUS oorhandig word. Stel in die remote-authentication-afdeling van die verbinding die metode op eap-radius en vra die EAP-identiteit eksplisiet aan. Die fragmente hieronder hoort binne 'n bestaande verbindingsblok, nie in 'n eie lêer nie. Bevestig die verbinding en die konfigurasie-agterkant voordat jy sintaksis uit 'n ander ontplooiing kopieer.

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

Met dit in plek ontvang die backend die identiteit wat die kliënt in die EAP-uitruiling verskaf, eerder as die IKE-adres. Niks anders aan die verbinding verander nie.

Of laat RADIUS die EAP-uitruiling begin

Die ander reëling plaas die eerste skuif aan die RADIUS-kant. Die inprop kan 'n EAP-Start-aanduiding stuur in plaas daarvan om op 'n aanvanklike identiteitsantwoord te wag, wat die bediener die uitruiling laat dryf. Dit is inpropvlak-konfigurasie, so dit raak elke verbinding wat die inprop gebruik.

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

Kies een reëling saam met die RADIUS-operateur eerder as om albei te aktiveer en te hoop. Hulle beskryf verskillende werkvloei, en 'n bediener wat verwag om te begin, sal nie noodwendig 'n poort hanteer wat die gesprek begin nie. Die inpropdokumentasie beskryf albei, insluitend watter identiteit elke stap dra.

Volg een poging deur albei logs

Korreleer 'n enkele poging oor albei logs. Kyk na die IKE-identiteit, dan of 'n EAP-Identity-uitruiling plaasvind, en dan watter naam die verifikasiestap ontvang. 'n Backend wat die adres voor die EAP-uitruiling verwerp, kan die proses stop voordat jou beoogde identiteit ooit gesien word.

journalctl -u strongswan -f

Hou die presiese gebruikersnaamformaat wat die identiteitstelsel verwag, insluitend die domeinvoorvoegsel. Moet nooit 'n rekening uit 'n adresvormige waarde uitdink nie, en skakel nooit verifikasie af om aan 'n beleidsreël te voldoen nie. 'n EAP-identiteit is 'n beweerde naam, en die metode moet dit steeds bewys. Skryf die resulterende naam in die toetsrekord sodat die volgende poging van 'n bekende toestand begin.

As die reggestelde vloei die regte rekening bereik en steeds verwerp word, is die volgende bewyse die EAP-metode en die backend-beleid, nie die identiteit nie. Om 'n wagwoordherstel te herhaal kan nie 'n waarde regmaak wat op 'n vroeër protokolvlak gekies is nie.

Verwante artikels