Bakit Nakikita ng RADIUS ang IP Address sa Halip na VPN Username

Kumokonekta ang isang Windows IKEv2 client, at dumarating ang RADIUS request na may address sa lugar kung saan dapat naroon ang pangalan ng account. Wala pang nabigo, at iyon ang nakakalito: iniuulat ng gateway ang identity na iniharap ng client sa IKE layer. Ang username na kailangan ng iyong backend ay maaaring nagmula sa hiwalay na EAP exchange na hindi pa nangyayari. Magpasya kung sino ang hihiling nito bago baguhin ang account.

Dalawang identity ang naglalakbay sa isang koneksyon

Maaaring lumitaw ang dalawang pangalan sa isang koneksyon. Kinikilala ng IKE identity ang peer habang nagsesetup ng tunnel, at ang eap-radius plugin ay kumokopya nito sa RADIUS User-Name sa simula. Ang EAP identity ay ibang value, ginagamit para sa pagpapatunay ng user, at maaaring hindi kailanman maipadala kung walang humihiling nito.

Kaya maaaring magpakita ang RADIUS log ng address habang umiiral ang account at tama ang password. Tinatanong ang backend tungkol sa maling layer. Ang RADIUS attribute ay transport lamang para sa napiling pangalan.

Hilingin sa gateway na humiling ng EAP identity

Isang sinusuportahang setup ang nagpapahiling sa gateway na humiling ng EAP identity bago ipasa ang authentication sa RADIUS. Sa seksyon ng remote authentication ng koneksyon, itakda ang method sa eap-radius at tahasang hilingin ang EAP identity. Ang fragment sa ibaba ay kabilang sa loob ng umiiral na connection block, hindi sa sariling file. Kumpirmahin ang koneksyon at ang configuration backend bago kopyahin ang syntax mula sa ibang deployment.

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

Sa gayon, natatanggap ng backend ang identity na ibinibigay ng client sa EAP exchange sa halip na ang IKE address. Wala nang ibang nagbabago sa koneksyon.

O hayaang ang RADIUS ang magsimula ng EAP exchange

Inilalagay ng ibang setup ang unang galaw sa panig ng RADIUS. Maaaring magpadala ang plugin ng EAP-Start indication sa halip na maghintay ng paunang identity response, na nagpapahintulot sa server na pangunahan ang exchange. Ito ay configuration sa antas ng plugin, kaya naaapektuhan nito ang bawat koneksyong gumagamit ng plugin.

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

Pumili ng isang setup kasama ng RADIUS operator sa halip na i-enable ang dalawa at umasa. Inilalarawan nila ang magkaibang workflow, at ang server na inaasahang magsisimula ay hindi laging kayang hawakan ang gateway na nagsisimula ng usapan. Inilalarawan ng dokumentasyon ng plugin ang dalawa, kasama kung aling identity ang dinadala ng bawat hakbang.

Sundan ang isang pagtatangka sa dalawang log

Iugnay ang isang pagtatangka sa dalawang log. Tingnan ang IKE identity, pagkatapos kung may EAP-Identity exchange, pagkatapos kung aling pangalan ang natatanggap ng authentication step. Ang backend na tumatanggi sa address bago ang EAP exchange ay maaaring ihinto ang proseso bago pa man makita ang nilalayon na identity.

journalctl -u strongswan -f

Panatilihin ang eksaktong format ng username na inaasahan ng identity system, kasama ang domain prefix. Huwag kailanman mag-imbento ng account mula sa value na hugis address, at huwag kailanman patayin ang authentication para matugunan ang isang policy rule. Ang EAP identity ay isang isinaad na pangalan, at kailangan pa rin itong patunayan ng method. Isulat ang resultang pangalan sa test record upang ang susunod na pagtatangka ay magsimula sa kilalang estado.

Kung naabot ng corrected flow ang tamang account at tinatanggihan pa rin, ang susunod na ebidensya ay ang EAP method at ang policy ng backend, hindi ang identity. Ang paulit-ulit na pag-reset ng password ay hindi makakapag-ayos ng value na pinili sa mas naunang protocol layer.