strongSwan EAP: pagkakakilanlang IKE laban sa inaasahang pangalang AAA

Ang pagpapatotoo ng EAP sa IKEv2 ay maaaring humiling sa kliyente na i-validate ang dalawang magkaibang pangalan ng server sa isang koneksyon. Ang gateway na nagtatapos sa IKE ay nagpapakita ng isang pagkakakilanlan, at ang backend ng EAP na nagtatapos sa panloob na palitan ng TLS ay maaaring magpakita ng iba. Sa strongSwan nakatira sila sa magkaibang bloke ng kompigurasyon, at ang paglalagay ng pangalan sa maling bloke ay lumilikha ng pagkabigo na mukhang problema sa sertipiko. Ang pagbasa kung aling pagpapatunay ang nabigo ang nagsasabi kung aling bloke ang aayusin.

Isang koneksyon, dalawang pagkakakilanlan ng server

Ang unang pagkakakilanlan ay kabilang sa palitan ng IKE. Tinatawagan ng kliyente ang isang address at inaasahan na patunayan ng kabilang panig ang isang partikular na pagkakakilanlan, karaniwang ang pangalan sa sertipiko ng gateway.

Ang pangalawa ay kabilang sa EAP. Sa PEAP o TTLS, nagtatayo ang kliyente ng lagusan ng TLS patungo sa server ng pagpapatotoo sa loob ng IKE SA, at ipinapakita ng panloob na server na iyon ang sarili nitong sertipiko. Kapag ang backend ay hiwalay na host, naiiba ang pangalan nito sa pangalan ng gateway. Ang kliyenteng sumusuri lamang sa unang pangalan ay tumatanggap kung ano man ang sinasabi ng pangalawa. At ang kliyenteng naka-kompigura sa isang pangalan sa dalawang lugar ay nabigo sa sandaling magkaiba talaga ang dalawa.

Ang dalawang pangalan ay nagmumula sa kompigurasyon ng operator, hindi sa sertipikong nag-aalis ng error. Ang pagtatanong sa operator tungkol sa mga detalye ng deployment ay mas mabilis kaysa sa paghula ng dalawang pangalan ng host.

Aling field ang kabilang sa aling layer

Sa swanctl, ang address at ang pagkakakilanlang IKE ay magkaibang setting, at ang pagkakakilanlang EAP ay pangatlo.

Pinipili ng malayong address kung saan pupunta ang mga packet, at sinasabi ng malayong pagkakakilanlan kung ano ang dapat patunayan ng kabilang panig. Ang inaasahan ng EAP ay isinusulat sa ilalim ng bloke ng local, dahil inilalarawan nito ang palitan ng EAP ng kliyenteng ito at hindi ang pag-uugali ng IKE ng kabilang panig. Ito mismong pagkakalagay ang mali ang pagbasa. Ang pangalan ay nasa kompigurasyon ng kliyente habang inilalarawan ang isang server, at iyon ang dahilan kung bakit mukhang mali ang lugar nito.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Ang bahaging iyon ay hindi kumpletong koneksyon; ang materyal ng pagtitiwala, mga kredensyal, at mga patakaran ng mga child connection ay dapat pa ring naroon. Ang kopyahin ito nang literal sa isang gumaganang file ay papalitan ang mga setting na kailangan mo pa.

Bakit nakatira ang aaa_id sa ilalim ng local

Inilalarawan ng bloke ng local kung ano ang ginagawa ng panig na ito sa panahon ng pagpapatotoo, kabilang ang paraang gagamitin at ang pagkakakilanlang inaasahan nito mula sa kabilang panig para sa paraang iyon. Wala rito ang nagsasabing tumatakbo ang server ng AAA sa parehong makina.

Ginagawang mas matalas ng default na halaga ang bitag. Kapag walang tahasang halaga na itinakda, sinusundan ng inaasahang pagkakakilanlang AAA ang malayong pagkakakilanlan, kaya gumagana ang deployment na may isang pangalan at itinatago ang pagkakaiba. Ang tahasang halaga ay mahalaga lamang kapag talagang nagtatapos ang deployment ng EAP sa ibang lugar. Ang itakda ito sa ibang pangalan nang walang ganoong dahilan ay lumilikha ng pagkabigong hindi maaaring kopyahin ng operator. Basahin ang deployment bago mag-imbento ng pangalawang pangalan.

Panatilihing kapareho ng aktwal na sinasabi ng sertipiko ng backend ang halaga, kabilang ang anyo ng pangalan. Ang tuldok sa dulo o wildcard na hindi sumasaklaw sa host ay sapat na para mabigo ang pagsusuri.

Mga frontend na hindi maipahayag ang paghahati

Ang profile ng NetworkManager ay hindi ang parehong interface ng kompigurasyon tulad ng swanctl. Ang plugin sa likod nito ay naglalantad ng mas makitid na hanay ng mga kontrol sa pagkakakilanlan, at kung alin ang umiiral ay depende sa naka-install na bersyon.

Mahalaga iyon kapag talagang kailangan ng deployment ang dalawang pangalan. Ang field na may label na pagkakakilanlan ng server ay maaaring mag-kompigura ng isang layer at hindi ang isa, kaya ang profile ay maaaring mukhang tama at mabigo pa rin sa panloob na pagsusuri. Suriin kung ano ang sinusuportahan ng naka-install na plugin bago ipagpalagay na maipahayag ng profile ang kaayusang ito. Kung hindi nito kaya, ang pagpili ay nasa operator: ibang landas ng provisioning, o isang naitamang disenyo ng pagkakakilanlan ng server. Ang pagpapahina sa PEAP o pagtanggap ng anumang pangalan ay binabago ang patakaran ng pagpapatotoo sa halip na ayusin ito.

Ang alternatibo ay hindi isang bagay na imbentuhin sa kliyente. Hilingin nang nakasulat ang sinusuportahang kaayusan, pagkatapos itago ang sagot na iyon kasama ng profile.

Ibahin ang hindi pagtutugma ng pagkakakilanlan sa isang sertipikong nag-expire

Ang hindi pagtutugma ng pangalan at ang nag-expire na sertipiko ay magkaibang pagkabigo, at ibinabahagi sila ng log. Basahin ang mensahe bago magpasya kung aling field ang babaguhin.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

Ang pagtatakda ng nilalayong pagkakakilanlang AAA ay hindi nagre-renew ng sertipiko ni nagtatatag ng pagtitiwala sa naglabas nito, at ang pag-renew ng sertipiko ay hindi nagwawasto ng maling inaasahang pangalan. Basahin kung aling pagpapatunay ang nabigo bago i-edit ang isa pang field ng pagkakakilanlan. Pagkatapos ay i-reload ang kompigurasyon at kumpirmahin na ipinapakita ng na-load na koneksyon ang halagang itinakda mo, dahil ang na-edit na file na hindi kailanman na-load ay walang binabago. Isulat ang dalawang pangalan at ang kanilang mga layer sa mga tala ng deployment.