Waarom RADIUS een IP-adres ziet in plaats van de VPN-gebruikersnaam

strongSwan kan de IKE-identiteit in RADIUS User-Name zetten vóór enige EAP-uitwisseling. Bepaal wie de accountidentiteit opvraagt en correleer daarna één poging.

Een Windows IKEv2-client maakt verbinding en het RADIUS-verzoek komt binnen met een adres waar de accountnaam hoort te staan. Er is nog niets mislukt, en dat is juist het verwarrende: de gateway meldt de identiteit die de client op de IKE-laag presenteerde. De gebruikersnaam die je backend wil, komt mogelijk uit een aparte EAP-uitwisseling die nog niet heeft plaatsgevonden. Bepaal wie erom vraagt voordat je het account wijzigt.

Twee identiteiten reizen in één verbinding

In één verbinding kunnen twee namen voorkomen. De IKE-identiteit identificeert de peer tijdens het opzetten van de tunnel, en de eap-radius-plugin kopieert die eerst naar RADIUS User-Name. De EAP-identiteit is een andere waarde, gebruikt voor gebruikersauthenticatie, en wordt misschien nooit verzonden als niemand erom vraagt.

Daarom kan het RADIUS-log een adres tonen terwijl het account bestaat en het wachtwoord correct is. De backend wordt naar de verkeerde laag gevraagd. Het RADIUS-attribuut is alleen het transport voor de naam die is gekozen.

Vraag de gateway om een EAP-identiteit

Eén ondersteunde opstelling laat de gateway de EAP-identiteit opvragen voordat de authenticatie aan RADIUS wordt overgedragen. Stel in het gedeelte voor remote-authenticatie van de verbinding de methode in op eap-radius en vraag de EAP-identiteit expliciet op. Het fragment hieronder hoort binnen een bestaand verbindingsblok, niet in een eigen bestand. Bevestig de verbinding en de configuratie-backend voordat je syntaxis uit een andere implementatie kopieert.

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

Daarmee ontvangt de backend de identiteit die de client in de EAP-uitwisseling levert in plaats van het IKE-adres. Verder verandert er niets aan de verbinding.

Of laat RADIUS de EAP-uitwisseling starten

De andere opstelling legt de eerste zet aan de RADIUS-kant. De plugin kan een EAP-Start-indicatie sturen in plaats van te wachten op een eerste identiteitsantwoord, waardoor de server de uitwisseling kan leiden. Dat is configuratie op pluginniveau, dus het beïnvloedt elke verbinding die de plugin gebruikt.

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

Kies één opstelling met de RADIUS-operator in plaats van beide in te schakelen en te hopen. Ze beschrijven verschillende werkstromen, en een server die verwacht te beginnen gaat niet noodzakelijk om met een gateway die het gesprek begint. De plugindocumentatie beschrijft beide, inclusief welke identiteit elke stap draagt.

Volg één poging door beide logs

Correleer één enkele poging in beide logs. Let op de IKE-identiteit, dan of een EAP-Identity-uitwisseling plaatsvindt, en dan welke naam de authenticatiestap ontvangt. Een backend die het adres vóór de EAP-uitwisseling weigert, kan het proces stoppen voordat je beoogde identiteit ooit te zien is.

journalctl -u strongswan -f

Behoud het exacte gebruikersnaamformaat dat het identiteitssysteem verwacht, inclusief het domeinprefix. Verzin nooit een account uit een adresvormige waarde, en schakel authenticatie nooit uit om een beleidsregel te vervullen. Een EAP-identiteit is een beweerde naam, en de methode moet die nog steeds bewijzen. Schrijf de resulterende naam in het testrecord zodat de volgende poging vanuit een bekende toestand begint.

Als de gecorrigeerde stroom het juiste account bereikt en nog steeds wordt geweigerd, is het volgende bewijs de EAP-methode en het backendbeleid, niet de identiteit. Het herhalen van een wachtwoordreset kan een waarde die op een eerdere protocol-laag is gekozen niet repareren.

Gerelateerde artikelen