Planlæg IKEv2-indstillinger, der passer til mere end én klient

En fungerende profil på én computer er en vellykket test af én klient. Det er ikke en tværplatformsudrulning, og hvis man behandler den som en, får man det velkendte supportmønster: Windows opretter forbindelse, telefonen fejler ved identitetskontrollen, og den administrerede bærbare computer genopretter forbindelsen hver gang, den vågner. Forskellene er reelle og stort set forudsigelige, og derfor bør planen være en matrix og ikke et skærmbillede.

Beslut identitetskontrakten først

Dokumentér serveridentiteten, certifikattilliden og metoden til klientgodkendelse, før I diskuterer algoritmer. De tre afgør, om en klient overhovedet kan godkende sig, og det er de dele, som platforme udtrykker forskelligt.

Undersøg, hvordan hver platform navngiver den forventede identifikator, og hvordan den håndterer alternative emnenavne. En profil, der accepterer et servernavn på én klient, kan afvise det samme certifikat på en anden, fordi identifikatorfeltet udfyldes fra en anden værdi.

Vælg derefter det kryptografiske fælles snit

Sammenlign de forslag, hver understøttet klient kan tilbyde, og vælg et moderne fælles snit, som gatewayen også tillader. Aktiver ikke en overdreven stor gammel liste, bare for at én gammel enhed kan oprette forbindelse, for den liste bliver gatewayens standard for alle, der følger efter. Skriv ned, hvorfor hver gammel mulighed stadig er der. Hvis ingen kan navngive den enhed, der har brug for den, er det ikke et krav.

Hold IKE- og CHILD-indstillinger adskilt i planen. Et forslag, der er acceptabelt til IKE-udvekslingen, er ikke automatisk acceptabelt til beskyttet trafik, og de to forhandles separat. En gateway, der accepterer et forslag på ét lag, kan stadig afvise det på det andet, og loggen vil vise en fejl, der ser ud som om det første lag lykkedes.

Klargør legitimationsoplysninger gennem en verificeret proces, og hold en brugeradgangskode, en delt hemmelighed og en klients private nøgle i deres egne felter. Prøv-og-fejl på enslydende bokse er måden, hvorpå en fungerende test bliver en, der ikke kan genskabes.

Test livscyklussen, ikke den stabile tilstand

Test for hver klient den indledende godkendelse, det tilsigtede program, DNS-opløsning og dækning af adressefamilier. Afprøv derefter de dele, der først viser sig senere: fornyelse, dvale og en normal netværksændring.

MOBIKE-understøttelse og adfærd ved genautentificering kan afvige fra det stabile resultat, du netop har målt. Registrér hændelsen og associeringens tilstand på det tidspunkt i stedet for kun, om grænsefladen til sidst ser ud til at være forbundet.

Definér, hvad direkte trafik må gøre, mens VPN ikke er tilgængeligt. Det er en politikbeslutning, der er adskilt fra, om klienten genopretter forbindelsen, og de fleste udrulninger besvarer det andet spørgsmål, mens de ignorerer det første. Skriv svaret i udrulningsnoterne ved siden af profilnavnene. Nogen får brug for det under et udfald og har ikke tid til at rekonstruere det.

Brug serveridentitetskontroller, når én platform er uenig

Når en profil virker på én platform, og en anden afviser dens navn, skal du sammenligne den identifikator, klienten faktisk sendte, med de identifikatorer, certifikatet bærer. Den sammenligning løser de fleste af disse sager hurtigere end at ændre cipher-lister.

Opbevar den testede matrix sammen med konfigurationskilden og opdateringsproceduren. Når supporten til en gammel klient ophører, skal du bevidst fjerne dens undtagelse i stedet for at lade svagere kompatibilitetsindstillinger ligge skjult i gatewayen til den næste revision. strongSwans IKEv2-dokumentation er en nyttig reference til, hvordan udvekslingerne konfigureres.