Plānojiet IKEv2 iestatījumus, kas der vairāk nekā vienam klientam
Strādājošs darbvirsmas profils ir pārbaudījis vienu klientu. Vienojieties par identitātes līgumu, izvēlieties atbalstītu šķēlumu un pēc tam pārbaudiet atjaunošanu un miegu katrai platformai.
Strādājošs profils vienā darbvirsmā ir viena klienta veiksmīga pārbaude. Tas nav vairāku platformu izvietojums, un, to tā uzskatot, rodas pazīstamais atbalsta modelis: Windows pieslēdzas, tālrunis neiztur identitātes pārbaudi, un pārvaldītais klēpjdators katru reizi pēc pamošanās pieslēdzas no jauna. Atšķirības ir reālas un lielākoties paredzamas, tāpēc plānam jābūt matricai, nevis ekrānuzņēmumam.
Vispirms nosakiet identitātes līgumu
Pirms algoritmu apspriešanas dokumentējiet servera identitāti, uzticēšanos sertifikātam un klienta autentifikācijas metodi. Šie trīs nosaka, vai klients vispār var autentificēties, un tieši tos platformas izsaka atšķirīgi.
Pārbaudiet, kā katra platforma nosauc gaidīto identifikatoru un kā tā apstrādā alternatīvos subjekta nosaukumus. Profils, kas pieņem servera nosaukumu vienā klientā, var noraidīt to pašu sertifikātu citā, jo identifikatora lauks tiek aizpildīts no citas vērtības.
| 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 |
Pēc tam izvēlieties kriptogrāfisko šķēlumu
Salīdziniet priekšlikumus, ko var piedāvāt katrs atbalstītais klients, un izvēlieties modernu šķēlumu, ko pieļauj arī vārteja. Neiespējojiet pārāk lielu veco sarakstu, lai pievienotos viena veca ierīce, jo šis saraksts kļūst par vārtejas noklusējumu visiem nākamajiem. Pierakstiet, kāpēc katra vecā iespēja joprojām ir. Ja neviens nevar nosaukt ierīci, kurai tā nepieciešama, tā nav prasība.
Plānā turiet IKE un CHILD iestatījumus atsevišķi. Priekšlikums, kas ir pieņemams IKE apmaiņai, nav automātiski pieņemams aizsargātajai plūsmai, un abi tiek apspriesti atsevišķi. Vārteja, kas pieņem priekšlikumu vienā slānī, joprojām var to noraidīt otrā, un žurnāls parādīs kļūdu, kas izskatās tā, it kā pirmais slānis būtu izdevies.
Nodrošiniet akreditācijas datus ar pārbaudītu procesu un turiet lietotāja paroli, koplietoto noslēpumu un klienta privāto atslēgu savos laukos. Mēģinājumi un kļūdas līdzīgi nosauktās kastēs ir ceļš, kā strādājoša pārbaude kļūst neatkārtojama.
Pārbaudiet dzīves ciklu, nevis stabilo stāvokli
Katram klientam pārbaudiet sākotnējo autentifikāciju, paredzēto lietojumprogrammu, DNS izšķiršanu un adrešu saimju pārklājumu. Pēc tam vingriniet daļas, kas parādās tikai vēlāk: atjaunošanu, miegu un parastu tīkla maiņu.
MOBIKE atbalsts un atkārtotas autentifikācijas uzvedība var atšķirties no tikko mērītā stabilā rezultāta. Reģistrējiet notikumu un asociācijas stāvokli tajā brīdī, nevis tikai to, vai saskarne galu galā izskatās pievienota.
Definējiet, ko tiešā plūsma drīkst darīt, kamēr VPN nav pieejams. Tas ir politikas lēmums, kas atšķiras no jautājuma, vai klients pieslēgsies no jauna, un lielākā daļa izvietojumu atbild uz otro jautājumu, ignorējot pirmo. Ierakstiet atbildi izvietošanas piezīmēs blakus profilu nosaukumiem. Kādam tā būs vajadzīga pārtraukuma laikā, un viņam nebūs laika to rekonstruēt.
Izmantojiet servera identitātes pārbaudes, kad viena platforma nepiekrīt
Kad profils darbojas vienā platformā un cita noraida tā nosaukumu, salīdziniet identifikatoru, ko klients faktiski nosūtīja, ar identifikatoriem, ko satur sertifikāts. Šis salīdzinājums atrisina lielāko daļu šo gadījumu ātrāk nekā šifru sarakstu maiņa.
Glabājiet pārbaudīto matricu kopā ar konfigurācijas avotu un atjaunināšanas procedūru. Kad atbalsts vecam klientam beidzas, apzināti noņemiet tā izņēmumu, tā vietā lai atstātu vājākus saderības iestatījumus paslēptus vārtejā nākamajam auditam. strongSwan IKEv2 dokumentācija ir noderīga atsauce par to, kā tiek konfigurētas apmaiņas.