Planlegg IKEv2-innstillinger som passer for mer enn én klient
En fungerende skrivebordsprofil har testet én klient. Bli enige om identitetskontrakten, velg et støttet snitt, og test deretter fornyelse og dvale per plattform.
En fungerende profil på ett skrivebord er en vellykket test av én klient. Det er ingen tverrplattform-utrulling, og behandler man den som det, får man det kjente støttemønsteret: Windows kobler til, telefonen feiler ved identitetskontrollen, og den administrerte bærbare maskinen kobler til på nytt hver gang den våkner. Forskjellene er reelle og stort sett forutsigbare, derfor bør planen være en matrise og ikke et skjermbilde.
Bestem identitetskontrakten først
Dokumenter serveridentiteten, sertifikattilliten og metoden for klientautentisering før dere diskuterer algoritmer. Disse tre avgjør om en klient i det hele tatt kan autentisere seg, og det er delene plattformene uttrykker ulikt.
Sjekk hvordan hver plattform navngir forventet identifikator og hvordan den håndterer alternative emnenavn. En profil som godtar et servernavn på én klient, kan avvise det samme sertifikatet på en annen fordi identifikatorfeltet fylles fra en annen verdi.
| 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 |
Velg deretter det kryptografiske snittet
Sammenlign forslagene hver støttet klient kan tilby, og velg et moderne snitt som gatewayen også tillater. Ikke aktiver en overdrevent stor gammel liste for at én gammel enhet skal koble til, for den listen blir gatewayens standard for alle som følger etter. Skriv ned hvorfor hvert gamle alternativ fortsatt er der. Hvis ingen kan navngi enheten som trenger det, er det ikke et krav.
Hold IKE- og CHILD-innstillinger adskilt i planen. Et forslag som er akseptabelt for IKE-utvekslingen, er ikke automatisk akseptabelt for beskyttet trafikk, og de to forhandles separat. En gateway som godtar et forslag i ett lag, kan fortsatt avvise det i det andre, og loggen vil vise en feil som ser ut som om det første laget lyktes.
Klargjør påloggingsinformasjon gjennom en verifisert prosess, og hold et brukerpassord, en delt hemmelighet og en klients private nøkkel i egne felt. Prøving og feiling på likt navngitte bokser er måten en fungerende test blir en som ikke kan gjenskapes.
Test livssyklusen, ikke den stabile tilstanden
For hver klient, test den første autentiseringen, den tiltenkte applikasjonen, DNS-oppslag og dekning av adressefamilier. Deretter øv på delene som først dukker opp senere: fornyelse, dvale og en vanlig nettverksendring.
MOBIKE-støtte og atferd ved reautentisering kan avvike fra det stabile resultatet du nettopp målte. Registrer hendelsen og assosiasjonens tilstand på det tidspunktet, ikke bare om grensesnittet til slutt ser tilkoblet ut.
Definer hva direkte trafikk kan gjøre mens VPN ikke er tilgjengelig. Det er en policybeslutning atskilt fra om klienten kobler til på nytt, og de fleste utrullinger svarer på det andre spørsmålet mens de ignorerer det første. Skriv svaret i utrullingsnotatene ved siden av profilnavnene. Noen vil trenge det under en avbrudd, og de vil ikke ha tid til å rekonstruere det.
Bruk serveridentitetskontroller når én plattform er uenig
Når en profil fungerer på én plattform og en annen avviser navnet, sammenlign identifikatoren klienten faktisk sendte med identifikatorene sertifikatet bærer. Den sammenligningen løser de fleste av disse sakene raskere enn å endre cipher-lister.
Oppbevar den testede matrisen sammen med konfigurasjonskilden og oppdateringsprosedyren. Når støtten for en gammel klient avsluttes, fjern unntaket bevisst i stedet for å la svakere kompatibilitetsinnstillinger ligge skjult i gatewayen for neste revisjon. strongSwans IKEv2-dokumentasjon er en nyttig referanse for hvordan utvekslingene konfigureres.