Wêrom't RADIUS in IP-adres sjocht yn stee fan de VPN-brûkersnamme

strongSwan kin de IKE-identiteit yn RADIUS User-Name sette foar't in EAP-útwikseling plakfynt. Beslis wa't de akkountidentiteit freget, en korrelearje dan ien besykjen.

In Windows IKEv2-klant makket ferbining, en it RADIUS-fersyk komt oan mei in adres dêr't de akkountnamme wêze moatte soe. Der is noch neat misgien, en dat is krekt it ferwarjende: de gateway rapportearret de identiteit dy't de klant op 'e IKE-laach oanbean hat. De brûkersnamme dy't jo backend wol, komt miskien út in aparte EAP-útwikseling dy't noch net bard is. Beslis wa't derom freget foar't jo it akkount feroarje.

Twa identiteiten reizgje yn ien ferbining

Twa nammen kinne yn ien ferbining foarkomme. De IKE-identiteit identifisearret de partner by it opsetten fan 'e tunnel, en de eap-radius-plug-in kopiearret dy earst nei RADIUS User-Name. De EAP-identiteit is in oare wearde, brûkt foar brûkersautentikaasje, en dy wurdt miskien nea ferstjoerd as nimmen derom freget.

Dêrom kin it RADIUS-log in adres sjen litte wylst it akkount bestiet en it wachtwurd goed is. De backend wurdt oer de ferkearde laach frege. It RADIUS-attribút is allinnich it ferfier foar de namme dy't keazen is.

Freegje de gateway om in EAP-identiteit

Ien stipe opstelling lit de gateway de EAP-identiteit freegje foar't de autentikaasje oan RADIUS oerdroegen wurdt. Yn 'e seksje foar remote-autentikaasje fan 'e ferbining sette jo de metoade op eap-radius en freegje de EAP-identiteit eksplisyt. It fragmint hjirûnder heart binnen in besteand ferbiningsblok, net yn in eigen bestân. Befêstigje de ferbining en de konfiguraasje-backend foar't jo syntaks fan in oare ynset kopiearje.

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

Dêrmei krijt de backend de identiteit dy't de klant yn 'e EAP-útwikseling leveret, yn stee fan it IKE-adres. Oars feroaret der neat oan 'e ferbining.

Of lit RADIUS de EAP-útwikseling begjinne

De oare opstelling leit de earste set by de RADIUS-kant. De plug-in kin in EAP-Start-oantsjutting stjoere yn stee fan te wachtsjen op in earste identiteitsantwurd, wat de server de útwikseling liede lit. Dat is konfiguraasje op plug-innivo, dus it beynfloedet elke ferbining dy't de plug-in brûkt.

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

Kies ien opstelling mei de RADIUS-operator yn stee fan beide oan te setten en te hoopjen. Se beskriuwe ferskate wurkstreamen, en in server dy't ferwachtet te begjinnen sil net needsaaklik in gateway oankinne dy't it petear begjint. De plug-yn-dokumintaasje beskriuwt beide, ynklusyf hokker identiteit elke stap draacht.

Folgje ien besykjen troch beide logs

Korrelearje ien besykjen oer beide logs. Sjoch nei de IKE-identiteit, dan oft in EAP-Identity-útwikseling bart, en dan hokker namme de autentikaasjestap krijt. In backend dy't it adres foar de EAP-útwikseling ôfwiist, kin it proses stopje foar't jo bedoelde identiteit ea sjoen wurdt.

journalctl -u strongswan -f

Hâld it krekte brûkersnammeformaat oan dat it identiteitssysteem ferwachtet, ynklusyf it domeinprefiks. Betink nea in akkount út in adresfoarmige wearde, en set autentikaasje nea út om in beliedsregel te foldwaan. In EAP-identiteit is in bewearde namme, en de metoade moat dy noch bewiisje. Skriuw de resultearjende namme yn it testrecord, sadat it folgjende besykjen fan in bekende steat begjint.

As de korrizjearre stream it juste akkount berikt en dochs ôfwiisd wurdt, is it folgjende bewiis de EAP-metoade en it backend-belied, net de identiteit. It werheljen fan in wachtwurdresets kin in wearde net reparearje dy't op in eardere protokollaach keazen is.

Relatearre artikelen