Kial RADIUS vidas IP-adreson anstataŭ la VPN-uzantnomo

strongSwan povas meti la IKE-identecon en RADIUS User-Name antaŭ iu ajn EAP-interŝanĝo. Decidu, kiu petas la kontan identecon, poste kunligu unu provon.

Windows IKEv2-kliento konektiĝas, kaj la RADIUS-peto alvenas kun adreso tie, kie devus esti la konta nomo. Nenio ankoraŭ malsukcesis, kaj ĝuste tio konfuzas: la enirejo raportas la identecon, kiun la kliento prezentis ĉe la IKE-tavolo. La uzantnomo, kiun via malantaŭa sistemo volas, eble venas el aparta EAP-interŝanĝo, kiu ankoraŭ ne okazis. Decidu, kiu petas ĝin, antaŭ ol ŝanĝi la konton.

Du identecoj vojaĝas en unu konekto

Du nomoj povas aperi en unu konekto. La IKE-identeco identigas la kunulon dum tunela starigo, kaj la kromaĵo eap-radius komence kopias ĝin en RADIUS User-Name. La EAP-identeco estas alia valoro, uzata por uzantaŭtentikigo, kaj ĝi eble neniam estos sendita, se neniu petas ĝin.

Tial la RADIUS-protokolo povas montri adreson, dum la konto ekzistas kaj la pasvorto estas ĝusta. La malantaŭa sistemo estas demandata pri la malĝusta tavolo. La RADIUS-atributo estas nur la transporto por la nomo, kiun oni elektis.

Petu la enirejon peti EAP-identecon

Unu subtenata aranĝo lasas la enirejon peti la EAP-identecon antaŭ ol transdoni aŭtentikigon al RADIUS. En la sekcio pri fora aŭtentikigo de la konekto, agordu la metodon al eap-radius kaj petu la EAP-identecon eksplicite. La suba fragmento apartenas ene de ekzistanta konekta bloko, ne en propra dosiero. Konfirmu la konekton kaj la agordan malantaŭan sistemon antaŭ ol kopii sintakson el alia deplojo.

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

Kun tio, la malantaŭa sistemo ricevas la identecon, kiun la kliento provizas en la EAP-interŝanĝo, anstataŭ la IKE-adreson. Nenio alia pri la konekto ŝanĝiĝas.

Aŭ lasu RADIUS komenci la EAP-interŝanĝon

La alia aranĝo metas la unuan movon ĉe la RADIUS-flanko. La kromaĵo povas sendi indikon EAP-Start anstataŭ atendi komencan identecan respondon, kio lasas la servilon gvidi la interŝanĝon. Tio estas agordo je kromaĵa nivelo, do ĝi efikas al ĉiu konekto, kiu uzas la kromaĵon.

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

Elektu unu aranĝon kun la RADIUS-operatoro anstataŭ ŝalti ambaŭ kaj esperi. Ili priskribas malsamajn laborfluojn, kaj servilo, kiu atendas komenci, ne nepre traktos enirejon, kiu komencas la konversacion. La dokumentaro de la kromaĵo priskribas ambaŭ, inkluzive kiun identecon portas ĉiu paŝo.

Sekvu unu provon tra ambaŭ protokoloj

Kunligu unu solan provon en ambaŭ protokoloj. Rigardu la IKE-identecon, poste ĉu okazas EAP-Identity-interŝanĝo, poste kiun nomon ricevas la aŭtentikiga paŝo. Malantaŭa sistemo, kiu rifuzas la adreson antaŭ la EAP-interŝanĝo, povas haltigi la procezon antaŭ ol via celata identeco iam videblas.

journalctl -u strongswan -f

Konservu la ĝustan uzantnoman formaton, kiun la identeca sistemo atendas, inkluzive la domajnan prefikson. Neniam elpensu konton el adresforma valoro, kaj neniam malŝaltu aŭtentikigon por kontentigi regulon de politiko. EAP-identeco estas asertita nomo, kaj la metodo ankoraŭ devas pruvi ĝin. Skribu la rezultan nomon en la testan protokolon, por ke la sekva provo komenciĝu de konata stato.

Se la korektita fluo atingas la ĝustan konton kaj ankoraŭ estas rifuzata, la sekva pruvo estas la EAP-metodo kaj la politiko de la malantaŭa sistemo, ne la identeco. Ripeti pasvortan restarigon ne povas ripari valoron elektitan ĉe pli frua protokola tavolo.

Rilataj artikoloj