strongSwan EAP: IKE-identiteit teenoor die verwagte AAA-naam

’n strongSwan EAP-kliënt kan twee bedienername valideer. remote.id dek die IKE-gateway en local.aaa_id dek die EAP-bediener; dit is nie een veld nie.

EAP-verifikasie oor IKEv2 kan van ’n kliënt verwag om twee verskillende bedienername in een verbinding te valideer. Die gateway wat IKE beëindig, bied een identiteit aan, en die EAP-agterkant wat die binnedste TLS-uitruiling beëindig, kan ’n ander een bied. In strongSwan woon hulle in verskillende konfigurasieblokke, en om ’n naam in die verkeerde een te sit, lewer ’n fout op wat soos ’n sertifikaatprobleem lyk. Om te lees watter validering misluk het, is wat jou vertel watter blok om te wysig.

Een verbinding, twee bedieneridentiteite

Die eerste identiteit hoort by die IKE-uitruiling. Die kliënt skakel ’n adres en verwag dat die eweknie ’n bepaalde identiteit bewys, gewoonlik die naam in die gateway-sertifikaat.

Die tweede hoort by EAP. Met PEAP of TTLS bou die kliënt ’n TLS-tonnel na die verifikasiebediener binne die IKE SA, en daardie binnedste bediener bied sy eie sertifikaat aan. Wanneer die agterkant ’n aparte gasheer is, verskil sy naam van die gateway s’n. ’n Kliënt wat net die eerste naam nagaan, aanvaar wat die tweede een ook al beweer. ’n Kliënt met een naam op albei plekke misluk sodra die twee werklik verskil.

Albei name kom uit die operateur se konfigurasie, nie uit watter sertifikaat ook al die fout laat verdwyn nie. Om die operateur om die ontplooiingsbesonderhede te vra, is vinniger as om twee gasheername te raai.

Watter veld hoort by watter laag

In swanctl is die adres en die IKE-identiteit aparte instellings, en die EAP-identiteit is ’n derde.

Die remote-adres kies waar pakkette heen gaan, en die remote-identiteit sê wat die eweknie moet bewys. Die EAP-verwagting staan onder die local-blok, want dit beskryf hierdie kliënt se EAP-uitruiling eerder as die eweknie se IKE-gedrag. Daardie plasing is die deel wat mense verkeerd lees. Die naam staan in die kliënt se konfigurasie terwyl dit ’n bediener beskryf, en dit is presies waarom dit verkeerd geplaas lyk.

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

Daardie fragment is nie ’n volledige verbinding nie; vertrouensmateriaal, geloofsbriewe en kind-beleide moet nog daar wees. Om dit woordeliks in ’n werkende lêer te kopieer, sou instellings vervang wat jy nog nodig het.

Waarom aaa_id onder local woon

Die local-blok beskryf wat hierdie kant tydens verifikasie doen, insluitend die metode wat dit sal gebruik en die identiteit wat dit van die ander kant vir daardie metode verwag. Niks daarin beweer die AAA-bediener loop op dieselfde masjien nie.

Die verstek maak die lokval skerper. Wanneer geen eksplisiete waarde gestel is nie, volg die verwagte AAA-identiteit die remote-identiteit, so ’n ontplooiing met een naam werk en verberg die onderskeid. ’n Eksplisiete waarde maak net saak wanneer die EAP-ontplooiing werklik elders eindig. Om dit na ’n ander naam te stel sonder daardie rede skep ’n fout wat die operateur nie kan weergee nie. Lees die ontplooiing voordat jy ’n tweede naam uitdink.

Hou die waarde identies aan wat die agterkant se sertifikaat werklik beweer, insluitend die vorm van die naam. ’n Punt aan die einde of ’n jokerteken wat nie die gasheer dek nie, is genoeg om die nagaan te laat misluk.

Voorkante wat die skeiding nie kan uitdruk nie

’n NetworkManager-profiel is nie dieselfde konfigurasiekoppelvlak as swanctl nie. Die inprop daaronder bied ’n smaller stel identiteitsbeheerders, en watter een bestaan hang van die geïnstalleerde weergawe af.

Dit maak saak wanneer die ontplooiing werklik twee name nodig het. ’n Veld gemerk bedieneridentiteit kan een laag instel en nie die ander nie, so ’n profiel kan korrek lyk en steeds die binnedste nagaan faal. Gaan na wat die geïnstalleerde inprop ondersteun voordat jy aanneem die profiel kan die reëling uitdruk. As dit nie kan nie, hoort die keuse by die operateur: ’n ander voorsieningspad, of ’n reggestelde ontwerp vir bedieneridentiteit. Om PEAP te verswak of enige naam te aanvaar, verander die verifikasiebeleid eerder as om dit reg te maak.

Die alternatief is nie iets om op die kliënt uit te dink nie. Vra die ondersteunde reëling skriftelik, en hou daardie antwoord by die profiel.

Onderskei ’n identiteitswanpassing van ’n vervalle sertifikaat

’n Naamwanpassing en ’n vervalle sertifikaat is verskillende foute, en die log onderskei hulle. Lees die boodskap voordat jy besluit watter veld om te wysig.

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

Om die bedoelde AAA-identiteit te stel, hernu nie ’n sertifikaat nie en vestig nie vertroue in sy uitreiker nie, en om ’n sertifikaat te hernu regstel nie ’n verkeerde verwagte naam nie. Lees watter validering misluk het voordat jy nog ’n identiteitsveld wysig. Laai dan die konfigurasie weer en bevestig dat die gelaaide verbinding die waarde toon wat jy gestel het, want ’n gewysigde lêer wat nooit gelaai is nie, verander niks. Skryf albei name en hulle lae in die ontplooiingsnotas.

Verwante artikels