Planeerige IKEv2 seaded, mis sobivad rohkem kui ühele kliendile
Töötav töölaua profiil on testinud ühte klienti. Leppige kokku identiteedileping, valige toetatud ühisosa ja seejärel testige uuendamist ja und iga platvormi jaoks.
Töötav profiil ühel töölaual on ühe kliendi edukas test. See ei ole platvormideülene juurutus ja kui seda sellisena käsitleda, tekib tuttav toe muster: Windows ühendub, telefon ebaõnnestub identiteedikontrollis ja hallatav sülearvuti ühendub uuesti iga kord, kui see ärkab. Erinevused on reaalsed ja valdavalt ennustatavad, seepärast peaks plaan olema maatriks, mitte ekraanipilt.
Otsustage esmalt identiteedileping
Dokumenteerige serveri identiteet, sertifikaadi usaldus ja kliendi autentimise meetod, enne kui arutate algoritme. Need kolm otsustavad, kas klient saab üldse autentida, ja just neid väljendavad platvormid erinevalt.
Kontrollige, kuidas iga platvorm oodatavat identifikaatorit nimetab ja kuidas see käsitleb subjekti alternatiivseid nimesid. Profiil, mis ühel kliendil aktsepteerib serveri nime, võib teisel sama sertifikaadi tagasi lükata, sest identifikaatori väli täidetakse teise väärtusega.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Seejärel valige krüptograafiline ühisosa
Võrrelge pakkumisi, mida iga toetatud klient saab pakkuda, ja valige kaasaegne ühisosa, mida lüüs samuti lubab. Ärge lubage ülemõõdulist vana nimekirja selleks, et üks vana seade ühenduks, sest see nimekiri saab lüüsi vaikeväärtuseks kõigile järgnevatele. Kirjutage üles, miks iga vana valik veel alles on. Kui keegi ei oska nimetada seadet, mis seda vajab, ei ole see nõue.
Hoidke IKE ja CHILD seaded plaanis eraldi. IKE-vahetuse jaoks vastuvõetav ettepanek ei ole automaatselt vastuvõetav kaitstud liikluse jaoks ja neid kahte läbiräägitakse eraldi. Lüüs, mis aktsepteerib ettepanekut ühes kihis, võib selle teises kihis siiski tagasi lükata, ja logi näitab tõrget, mis näeb välja nii, nagu esimene kiht oleks õnnestunud.
Hankige volitused kontrollitud protsessi kaudu ja hoidke kasutaja parooli, jagatud saladust ja kliendi privaatvõtit eraldi väljadel. Katsetamine ja eksimine sarnaselt nimetatud kastidega on viis, kuidas töötavast testist saab mittekorratav.
Testige elutsüklit, mitte püsiseisundit
Iga kliendi puhul testige algset autentimist, kavandatud rakendust, DNS-i lahendamist ja aadresside perekondade katvust. Seejärel harjutage osi, mis ilmnevad alles hiljem: uuendamine, uni ja tavaline võrgu muudatus.
MOBIKE tugi ja uuesti autentimise käitumine võivad erineda püsiseisundi tulemusest, mille just mõõtsite. Registreerige sündmus ja seose olek tollel hetkel, mitte ainult see, kas liides lõpuks ühendatud välja näeb.
Määratlege, mida otsene liiklus tohib teha, kui VPN ei ole saadaval. See on poliitikaotsus, mis on lahus sellest, kas klient ühendub uuesti, ja enamik juurutusi vastab teisele küsimusele, jättes esimese tähelepanuta. Kirjutage vastus juurutuse märkmetesse profiilide nimede kõrvale. Kellelgi läheb seda katkestuse ajal vaja ja tal ei ole aega seda rekonstrueerida.
Kasutage serveri identiteedi kontrolle, kui üks platvorm ei ole nõus
Kui profiil töötab ühel platvormil ja teine lükkab selle nime tagasi, võrrelge identifikaatorit, mille klient tegelikult saatis, identifikaatoritega, mida sertifikaat kannab. See võrdlus lahendab enamiku sellistest juhtumitest kiiremini kui šifri nimekirjade muutmine.
Hoidke testitud maatriksit koos konfiguratsiooni allika ja uuendusprotseduuriga. Kui vana kliendi tugi lõpeb, eemaldage selle erand teadlikult, selle asemel et jätta nõrgemad ühilduvusseaded lüüsi peidetult järgmise auditi leida. strongSwan IKEv2 dokumentatsioon on kasulik viide selle kohta, kuidas vahetusi konfigureeritakse.