strongSwan EAP: identitatea IKE față de numele AAA așteptat

Un client strongSwan EAP poate valida două nume de server. remote.id acoperă gateway-ul IKE, iar local.aaa_id acoperă serverul EAP; nu sunt același câmp.

Autentificarea EAP peste IKEv2 poate cere clientului să valideze două nume de server diferite într-o singură conexiune. Gateway-ul care încheie IKE prezintă o identitate, iar backend-ul EAP care încheie schimbul TLS interior poate prezenta alta. În strongSwan ele locuiesc în blocuri de configurare diferite, iar un nume în blocul greșit produce o eroare care pare o problemă de certificat. Tocmai citirea verificării care a eșuat arată ce bloc trebuie editat.

O conexiune, două identități de server

Prima identitate aparține schimbului IKE. Clientul apelează o adresă și așteaptă ca partea cealaltă să dovedească o identitate anume, de obicei numele din certificatul gateway-ului.

A doua aparține EAP. Cu PEAP sau TTLS, clientul construiește un tunel TLS către serverul de autentificare din interiorul IKE SA, iar acel server interior își prezintă propriul certificat. Când backend-ul este un host separat, numele lui diferă de cel al gateway-ului. Un client care verifică doar primul nume acceptă ce afirmă al doilea. Iar un client configurat cu un singur nume în ambele locuri eșuează de îndată ce cele două chiar diferă.

Ambele nume vin din configurația operatorului, nu din certificatul care face eroarea să dispară. A întreba operatorul despre detaliile implementării este mai rapid decât a ghici două nume de host.

Ce câmp aparține cărei straturi

În swanctl, adresa și identitatea IKE sunt setări separate, iar identitatea EAP este a treia.

Adresa la distanță alege încotro merg pachetele, iar identitatea la distanță spune ce trebuie să dovedească partea cealaltă. Așteptarea EAP se scrie sub blocul local, pentru că descrie schimbul EAP al acestui client, nu comportamentul IKE al celeilalte părți. Exact această plasare este citită greșit. Numele stă în configurația clientului în timp ce descrie un server, și de aceea pare nepotrivit.

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

Acest fragment nu este o conexiune completă; materialul de încredere, acreditările și politicile conexiunilor copil trebuie să fie încă prezente. Copierea lui textual într-un fișier de lucru ar înlocui setări de care ai încă nevoie.

De ce aaa_id stă sub local

Blocul local descrie ce face acest capăt în timpul autentificării, inclusiv metoda pe care o va folosi și identitatea pe care o așteaptă de la celălalt capăt pentru acea metodă. Nimic din el nu afirmă că serverul AAA rulează pe aceeași mașină.

Valoarea implicită face capcana mai ascuțită. Când nu este setată o valoare explicită, identitatea AAA așteptată urmează identitatea la distanță, așa că o implementare cu un singur nume funcționează și ascunde distincția. O valoare explicită contează doar când implementarea EAP se termină într-adevăr în altă parte. Setarea ei la alt nume fără acel motiv creează o eroare pe care operatorul nu o poate reproduce. Citește implementarea înainte de a inventa un al doilea nume.

Păstrează valoarea identică cu ce afirmă de fapt certificatul backend-ului, inclusiv forma numelui. Un punct final sau un wildcard care nu acoperă hostul este suficient pentru ca verificarea să eșueze.

Interfețe care nu pot exprima separarea

Un profil NetworkManager nu este aceeași interfață de configurare ca swanctl. Pluginul din spatele lui expune un set mai îngust de controale de identitate, iar care există depinde de versiunea instalată.

Asta contează când implementarea are într-adevăr nevoie de două nume. Un câmp etichetat identitate de server poate configura un strat și nu pe celălalt, așa că un profil poate părea corect și totuși poate eșua verificarea internă. Verifică ce suportă pluginul instalat înainte de a presupune că profilul poate exprima această aranjare. Dacă nu poate, alegerea aparține operatorului: o altă cale de provizionare sau un design corectat al identității serverului. Slăbirea PEAP sau acceptarea oricărui nume schimbă politica de autentificare în loc să o repare.

Alternativa nu este ceva de inventat pe client. Cere aranjarea suportată în scris, apoi păstrează răspunsul împreună cu profilul.

Distinge o nepotrivire de identitate de un certificat expirat

O nepotrivire de nume și un certificat expirat sunt erori diferite, iar jurnalul le distinge. Citește mesajul înainte de a decide ce câmp să schimbi.

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

Setarea identității AAA dorite nu reînnoiește un certificat și nu stabilește încredere în emitentul lui, iar reînnoirea unui certificat nu corectează un nume așteptat greșit. Citește care verificare a eșuat înainte de a edita un alt câmp de identitate. Apoi reîncarcă configurația și confirmă că conexiunea încărcată arată valoarea setată, fiindcă un fișier editat care nu a fost niciodată încărcat nu schimbă nimic. Scrie ambele nume și straturile lor în notele de implementare.

Articole similare