Miksi RADIUS näkee IP-osoitteen VPN-käyttäjänimen sijaan

strongSwan voi sijoittaa IKE-identiteetin RADIUS User-Name -kenttään ennen mitään EAP-vaihtoa. Päättäkää, kuka pyytää tilin identiteetin, ja korreloikaa sitten yksi yritys.

Windows IKEv2 -asiakas muodostaa yhteyden, ja RADIUS-pyyntö saapuu osoitteella, jossa tilin nimen pitäisi olla. Mikään ei ole vielä epäonnistunut, ja juuri se hämmentää: yhdyskäytävä raportoi identiteetin, jonka asiakas esitti IKE-kerroksessa. Käyttäjänimi, jonka taustajärjestelmänne haluaa, voi tulla erillisestä EAP-vaihdosta, jota ei ole vielä tapahtunut. Päättäkää, kuka sitä pyytää, ennen kuin muutatte tiliä.

Kaksi identiteettiä matkustaa yhdessä yhteydessä

Yhdessä yhteydessä voi esiintyä kaksi nimeä. IKE-identiteetti tunnistaa vastapuolen tunnelin pystytysvaiheessa, ja eap-radius-liitännäinen kopioi sen aluksi RADIUS User-Name -kenttään. EAP-identiteetti on eri arvo, jota käytetään käyttäjän todentamiseen, eikä sitä välttämättä koskaan lähetetä, jos kukaan ei pyydä sitä.

Siksi RADIUS-loki voi näyttää osoitteen, vaikka tili on olemassa ja salasana on oikein. Taustajärjestelmältä kysytään väärästä kerroksesta. RADIUS-attribuutti on vain valitun nimen kuljetus.

Pyytäkää yhdyskäytävää pyytämään EAP-identiteettiä

Yksi tuettu järjestely saa yhdyskäytävän pyytämään EAP-identiteetin ennen kuin se luovuttaa todentamisen RADIUS-palvelulle. Asettakaa yhteyden etätodennusosassa menetelmäksi eap-radius ja pyytäkää EAP-identiteetti nimenomaisesti. Alla oleva katkelma kuuluu olemassa olevan yhteyslohkon sisään, ei omaan tiedostoon. Vahvistakaa yhteys ja kokoonpanon taustajärjestelmä ennen kuin kopioitte syntaksia toisesta käyttöönotosta.

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

Sen kanssa taustajärjestelmä saa identiteetin, jonka asiakas antaa EAP-vaihdossa, IKE-osoitteen sijaan. Mikään muu yhteydessä ei muutu.

Tai antakaa RADIUS-palvelun aloittaa EAP-vaihto

Toinen järjestely jättää ensimmäisen siirron RADIUS-puolelle. Liitännäinen voi lähettää EAP-Start-ilmaisun sen sijaan, että odottaisi ensimmäistä identiteettivastausta, mikä antaa palvelimelle mahdollisuuden ohjata vaihtoa. Se on liitännäistason kokoonpano, joten se vaikuttaa jokaiseen yhteyteen, joka käyttää liitännäistä.

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

Valitkaa yksi järjestely RADIUS-operaattorin kanssa sen sijaan, että ottaisitte molemmat käyttöön ja toivoisitte. Ne kuvaavat erilaisia työnkulkuja, eikä palvelin, joka odottaa aloittavansa, välttämättä selviä yhdyskäytävästä, joka aloittaa keskustelun. Liitännäisen dokumentaatio kuvaa molemmat, mukaan lukien sen, mitä identiteettiä kukin vaihe kantaa.

Seuratkaa yhtä yritystä molemmissa lokeissa

Korreloikaa yksi yritys molemmissa lokeissa. Katsokaa IKE-identiteettiä, sitten tapahtuuko EAP-Identity-vaihto, ja sitten minkä nimen todentamisvaihe saa. Taustajärjestelmä, joka hylkää osoitteen ennen EAP-vaihtoa, voi pysäyttää prosessin ennen kuin aiottu identiteettinne näkyy koskaan.

journalctl -u strongswan -f

Säilyttäkää täsmälleen se käyttäjänimimuoto, jota identiteettijärjestelmä odottaa, verkkotunnuksen etuliite mukaan lukien. Älkää koskaan keksikö tiliä osoitteen muotoisesta arvosta älkääkä koskaan kytkekö todentamista pois käytöstä käytäntösäännön täyttämiseksi. EAP-identiteetti on esitetty nimi, ja menetelmän on silti todistettava se. Kirjoittakaa tuloksena oleva nimi testitietueeseen, jotta seuraava yritys alkaa tunnetusta tilasta.

Jos korjattu kulku saavuttaa oikean tilin ja se hylätään silti, seuraava todiste on EAP-menetelmä ja taustajärjestelmän käytäntö, ei identiteetti. Salasanan nollauksen toistaminen ei voi korjata arvoa, joka valittiin aikaisemmassa protokollakerroksessa.

Aiheeseen liittyvät artikkelit