Planirajte IKEv2 postavke koje odgovaraju više od jednog klijenta
Radni desktop profil testirao je jedan klijent. Uskladite ugovor o identitetu, odaberite podržani presjek, zatim testirajte obnavljanje i spavanje po platformi.
Radni profil na jednom desktopu uspješan je test jednog klijenta. To nije višeplatformsko postavljanje, a ako se tako tretira, nastaje poznati obrazac podrške: Windows se povezuje, telefon pada na provjeri identiteta, a upravljani laptop se ponovno povezuje svaki put kada se probudi. Razlike su stvarne i uglavnom predvidive, zato plan treba biti matrica, a ne snimak ekrana.
Prvo odredite ugovor o identitetu
Dokumentirajte identitet servera, povjerenje u certifikat i metodu autentifikacije klijenta prije rasprave o algoritmima. Ta tri određuju može li se klijent uopće autentificirati, i upravo ih platforme izražavaju različito.
Provjerite kako svaka platforma imenuje očekivani identifikator i kako obrađuje alternativna imena subjekta. Profil koji prihvata ime servera na jednom klijentu može odbiti isti certifikat na drugom jer se polje identifikatora popunjava drugom vrijednošću.
| 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 |
Zatim odaberite kriptografski presjek
Uporedite prijedloge koje svaki podržani klijent može ponuditi i odaberite moderni presjek koji gateway također dopušta. Ne uključujte preveliku staru listu da bi se povezao jedan stari uređaj, jer ta lista postaje zadana postavka gatewaya za sve koji slijede. Zapišite zašto je svaka stara opcija još tu. Ako niko ne može navesti uređaj kojem je potrebna, to nije zahtjev.
Držite IKE i CHILD postavke odvojenima u planu. Prijedlog prihvatljiv za IKE razmjenu nije automatski prihvatljiv za zaštićeni promet, a njih dvoje se pregovaraju odvojeno. Gateway koji prihvati prijedlog na jednom sloju ipak ga može odbiti na drugom, a log će pokazati grešku koja izgleda kao da je prvi sloj uspio.
Osigurajte akreditive provjerenim postupkom i držite korisničku lozinku, zajedničku tajnu i privatni ključ klijenta u vlastitim poljima. Pokušaji i pogreške na kutijama sličnih naziva put su kojim radni test postaje neponovljiv.
Testirajte životni ciklus, a ne stabilno stanje
Za svaki klijent testirajte početnu autentifikaciju, predviđenu aplikaciju, DNS razrješavanje i pokrivenost porodica adresa. Zatim vježbajte dijelove koji se pojavljuju tek kasnije: obnavljanje, spavanje i normalnu promjenu mreže.
Podrška za MOBIKE i ponašanje pri ponovnoj autentifikaciji mogu se razlikovati od stabilnog rezultata koji ste upravo izmjerili. Zabilježite događaj i stanje asocijacije u tom trenutku, a ne samo to da li interfejs na kraju izgleda povezan.
Definirajte šta direktni promet smije raditi dok VPN nije dostupan. To je politička odluka odvojena od toga hoće li se klijent ponovno povezati, a većina postavljanja odgovara na drugo pitanje dok ignorira prvo. Zapišite odgovor u bilješke o postavljanju pored naziva profila. Nekome će trebati tokom pada mreže, a neće imati vremena da ga rekonstruiše.
Koristite provjere identiteta servera kada se jedna platforma ne slaže
Kada profil radi na jednoj platformi, a druga odbije njegovo ime, uporedite identifikator koji je klijent zaista poslao s identifikatorima koje nosi certifikat. To poređenje rješava većinu takvih slučajeva brže od mijenjanja lista šifri.
Čuvajte testiranu matricu uz izvor konfiguracije i proceduru ažuriranja. Kada se podrška za stari klijent završi, namjerno uklonite njegov izuzetak umjesto da slabije postavke kompatibilnosti ostavite skrivene na gatewayu za sljedeću reviziju. strongSwan IKEv2 dokumentacija koristan je izvor o tome kako se razmjene konfiguriraju.