Planu IKEv2-agordojn taŭgajn por pli ol unu kliento
Funkcianta labortabla profilo testis unu klienton. Interkonsentu la identec-kontrakton, elektu subtenatan komunaĵon, poste testu renovigon kaj dormon por ĉiu platformo.
Funkcianta profilo sur unu labortablo estas sukcesa testo de unu kliento. Ĝi ne estas transplatforma surmeto, kaj trakti ĝin kiel tian produktas la konatan subtenan ŝablonon: Windows konektiĝas, la telefono malsukcesas ĉe la identec-kontrolo, kaj la administrata tekkomputilo rekonektiĝas ĉiufoje, kiam ĝi vekiĝas. La diferencoj estas realaj kaj plejparte antaŭvideblaj, tial la plano devus esti matrico, ne ekrankopio.
Unue decidu la identec-kontrakton
Dokumentu la servilan identecon, la fidon al la atestilo kaj la metodon de klienta aŭtentigo antaŭ ol diskuti algoritmojn. Tiuj tri decidas, ĉu kliento entute povas aŭtentigi, kaj ili estas la partoj, kiujn platformoj esprimas malsame.
Kontrolu, kiel ĉiu platformo nomas la atendatan identigilon kaj kiel ĝi traktas alternativajn subjektajn nomojn. Profilo, kiu akceptas servilan nomon ĉe unu kliento, povas malakcepti la saman atestilon ĉe alia, ĉar la identigila kampo pleniĝas el malsama valoro.
| 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 |
Poste elektu la kriptografian komunaĵon
Komparu la proponojn, kiujn ĉiu subtenata kliento povas proponi, kaj elektu modernan komunaĵon, kiun ankaŭ la pordego permesas. Ne ŝaltu tro grandan malnovan liston por ke unu malnova aparato konektiĝu, ĉar tiu listo fariĝas la defaŭlto de la pordego por ĉiuj posteuloj. Skribu, kial ĉiu malnova opcio ankoraŭ estas. Se neniu povas nomi la aparaton, kiu bezonas ĝin, ĝi ne estas postulo.
Tenu IKE- kaj CHILD-agordojn apartaj en la plano. Propono akceptebla por la IKE-interŝanĝo ne estas aŭtomate akceptebla por protektita trafiko, kaj la du estas intertraktataj aparte. Pordego, kiu akceptas proponon ĉe unu tavolo, ankoraŭ povas rifuzi ĝin ĉe la alia, kaj la protokolo montros malsukceson, kiu aspektas kvazaŭ la unua tavolo sukcesis.
Provizu akreditaĵojn per kontrolita procezo, kaj tenu uzantan pasvorton, komunan sekreton kaj privatan ŝlosilon de la kliento en propraj kampoj. Provado kaj erarado sur simile nomitaj skatoloj estas la maniero, kiel funkcianta testo fariĝas nereproduktebla.
Testu la vivociklon, ne la stabilan staton
Por ĉiu kliento, testu la komencan aŭtentigon, la celatan aplikaĵon, DNS-rezolvon kaj kovradon de adresaj familioj. Poste ekzercu la partojn, kiuj aperas nur poste: renovigo, dormo kaj normala reta ŝanĝo.
MOBIKE-subteno kaj reaŭtentiga konduto povas diferenci de la stabila rezulto, kiun vi ĵus mezuris. Registru la eventon kaj la asocian staton en tiu momento, ne nur ĉu la interfaco finfine aspektas konektita.
Difinu, kion rekta trafiko rajtas fari dum la VPN ne disponeblas. Tio estas politika decido aparta de ĉu la kliento rekonektiĝas, kaj la plej multaj surmetoj respondas la duan demandon dum ili ignoras la unuan. Skribu la respondon en la surmetajn notojn apud la profilnomoj. Iu bezonos ĝin dum interrompo, kaj li ne havos tempon rekonstrui ĝin.
Uzu servil-identecajn kontrolojn, kiam unu platformo malkonsentas
Kiam profilo funkcias sur unu platformo kaj alia rifuzas ĝian nomon, komparu la identigilon, kiun la kliento efektive sendis, kun la identigiloj, kiujn la atestilo portas. Tiu komparo solvas la plej multajn el tiuj kazoj pli rapide ol ŝanĝi ĉifrajn listojn.
Konservu la testitan matricon kune kun la agorda fonto kaj la ĝisdatiga proceduro. Kiam subteno por malnova kliento finiĝas, forigu ĝian escepton intence, anstataŭ lasi pli malfortajn kongruecajn agordojn kaŝitajn en la pordego por la sekva revizio trovi. La IKEv2-dokumentaro de strongSwan estas utila referenco pri tio, kiel la interŝanĝoj agordiĝas.