Radni profil na jednom računalu uspješan je test jednog klijenta. To nije višeplatformska implementacija, a ako se tako tretira, nastaje poznati obrazac podrške: Windows se povezuje, telefon pada na provjeri identiteta, a upravljani prijenosnik ponovno se povezuje svaki put kada se probudi. Razlike su stvarne i uglavnom predvidive, zato plan treba biti matrica, a ne snimka zaslona.

Prvo odredite ugovor o identitetu

Dokumentirajte identitet poslužitelja, povjerenje u certifikat i metodu autentikacije 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 prihvaća ime poslužitelja na jednom klijentu može odbiti isti certifikat na drugom jer se polje identifikatora popunjava drugom vrijednošću.

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

Zatim odaberite kriptografski presjek

Usporedite prijedloge koje svaki podržani klijent može ponuditi i odaberite moderni presjek koji gateway također dopušta. Ne uključujte prevelik popis starih opcija da bi se povezao jedan stari uređaj, jer taj popis postaje zadana postavka gatewaya za sve koji slijede. Zapišite zašto je svaka stara opcija još tu. Ako nitko 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 pregovara se odvojeno. Gateway koji prihvati prijedlog na jednom sloju ipak ga može odbiti na drugom, a zapisnik ć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 autentikaciju, predviđenu aplikaciju, DNS razrješavanje i pokrivenost obitelji adresa. Zatim vježbajte dijelove koji se pojavljuju tek kasnije: obnavljanje, mirovanje i normalnu promjenu mreže.

Podrška za MOBIKE i ponašanje pri ponovnoj autentikaciji 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 sučelje na kraju izgleda povezano.

Definirajte što izravni 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 implementacija odgovara na drugo pitanje dok ignorira prvo. Zapišite odgovor u bilješke o implementaciji pokraj naziva profila. Nekome će trebati tijekom prekida, a neće imati vremena da ga rekonstruira.

Koristite provjere identiteta poslužitelja kada se jedna platforma ne slaže

Kada profil radi na jednoj platformi, a druga odbije njegovo ime, usporedite identifikator koji je klijent stvarno poslao s identifikatorima koje nosi certifikat. Ta usporedba rješava većinu takvih slučajeva brže od mijenjanja popisa šifri.

Čuvajte testiranu matricu uz izvor konfiguracije i postupak ažuriranja. Kada podrška za stari klijent završi, namjerno uklonite njegovu iznimku umjesto da slabije postavke kompatibilnosti ostavite skrivene na gatewayu za sljedeću reviziju. strongSwan IKEv2 dokumentacija koristan je izvor o tome kako se konfiguriraju razmjene.

Povezani članci