Veikiantis profilis viename darbalaukyje yra sėkmingas vieno kliento bandymas. Tai nėra kelių platformų diegimas, o traktuojant jį taip atsiranda pažįstamas palaikymo modelis: Windows prisijungia, telefonas nepraeina tapatybės patikros, o valdomas nešiojamasis kompiuteris kaskart pabudęs prisijungia iš naujo. Skirtumai yra realūs ir dažniausiai nuspėjami, todėl planas turėtų būti matrica, o ne ekrano kopija.

Pirmiausia nustatykite tapatybės sutartį

Prieš aptardami algoritmus dokumentuokite serverio tapatybę, pasitikėjimą sertifikatu ir kliento autentifikavimo metodą. Šie trys nusprendžia, ar klientas apskritai gali autentifikuotis, ir būtent juos platformos išreiškia skirtingai.

Patikrinkite, kaip kiekviena platforma įvardija laukiamą identifikatorių ir kaip tvarko alternatyvius subjekto pavadinimus. Profilis, priimantis serverio vardą viename kliente, gali atmesti tą patį sertifikatą kitame, nes identifikatoriaus laukas užpildomas kita reikšme.

Contract elementWhat to decideWhere platforms diverge
Server identityName or address the client must seeIdentifier field and SAN matching
Client authenticationCertificate, EAP method or bothWhich EAP variants exist and how prompts appear
Trust anchorWhich CA and how it is deliveredStore location and provisioning path

Tada pasirinkite kriptografinę sankirtą

Palyginkite pasiūlymus, kuriuos gali pateikti kiekvienas palaikomas klientas, ir pasirinkite šiuolaikinę sankirtą, kurią leidžia ir šliuzas. Neįjunkite pernelyg didelio seno sąrašo, kad prisijungtų vienas senas įrenginys, nes tas sąrašas tampa šliuzo numatytuoju nustatymu visiems vėlesniems. Užrašykite, kodėl kiekviena sena parinktis vis dar yra. Jei niekas negali įvardyti įrenginio, kuriam jos reikia, tai nėra reikalavimas.

Plane laikykite IKE ir CHILD nustatymus atskirai. Pasiūlymas, priimtinas IKE mainams, nėra automatiškai priimtinas apsaugotam srautui, ir abu derinami atskirai. Šliuzas, priimantis pasiūlymą viename sluoksnyje, vis tiek gali jo atsisakyti kitame, o žurnalas parodys gedimą, kuris atrodo tarsi pirmas sluoksnis pavyko.

Suteikite kredencialus patikrintu procesu ir laikykite naudotojo slaptažodį, bendrą paslaptį bei kliento privatų raktą savo laukuose. Bandymai ir klaidos panašiai pavadintose dėžėse yra kelias, kuriuo veikiantis bandymas tampa nepakartojamas.

Bandykite gyvavimo ciklą, o ne stabilią būseną

Kiekvienam klientui išbandykite pradinę autentifikaciją, numatytą programą, DNS sprendimą ir adresų šeimų aprėptį. Tada praktikuokite dalis, kurios atsiranda tik vėliau: atnaujinimą, miegą ir įprastą tinklo pokytį.

MOBIKE palaikymas ir pakartotinės autentifikacijos elgsena gali skirtis nuo ką tik išmatuoto stabilaus rezultato. Užfiksuokite įvykį ir asociacijos būseną tuo metu, o ne tik tai, ar sąsaja galiausiai atrodo prisijungusi.

Apibrėžkite, ką tiesioginis srautas gali daryti, kol VPN nepasiekiamas. Tai politikos sprendimas, atskiras nuo to, ar klientas prisijungs iš naujo, ir dauguma diegimų atsako į antrą klausimą, ignoruodami pirmą. Užrašykite atsakymą diegimo pastabose šalia profilių pavadinimų. Kažkam jo prireiks sutrikimo metu, ir jis neturės laiko jo atkurti.

Naudokite serverio tapatybės patikras, kai viena platforma nesutinka

Kai profilis veikia vienoje platformoje, o kita atmeta jo pavadinimą, palyginkite identifikatorių, kurį klientas iš tikrųjų nusiuntė, su identifikatoriais, kuriuos turi sertifikatas. Šis palyginimas išsprendžia daugumą tokių atvejų greičiau nei šifrų sąrašų keitimas.

Saugokite išbandytą matricą kartu su konfigūracijos šaltiniu ir atnaujinimo procedūra. Kai seno kliento palaikymas baigiasi, sąmoningai pašalinkite jo išimtį, o ne palikite silpnesnius suderinamumo nustatymus paslėptus šliuze kitam auditui rasti. strongSwan IKEv2 dokumentacija yra naudinga nuoroda apie tai, kaip konfigūruojami mainai.

Susiję straipsniai