Planlegg IKEv2-innstillingar som passar for meir enn éin klient

Ein fungerande profil på éin skrivebord er ein vellukka test av éin klient. Det er ikkje ein tverrplattform-utrulling, og handsamar ein han som det, får ein det kjende støttemønsteret: Windows koplar til, telefonen feilar ved identitetskontrollen, og den administrerte berbare maskinen koplar til på nytt kvar gong han vaknar. Skilnadene er reelle og stort sett føreseielege, difor bør planen vere ein matrise og ikkje eit skjermbilete.

Fastset identitetskontrakten først

Dokumenter serveridentiteten, sertifikattilliten og metoden for klientautentisering før de diskuterer algoritmar. Desse tre avgjer om ein klient i det heile kan autentisere seg, og det er delane plattformane uttrykkjer ulikt.

Sjekk korleis kvar plattform namngir forventa identifikator og korleis ho handterer alternative emnenamn. Ein profil som godtek eit servernamn på éin klient, kan avvise det same sertifikatet på ein annan fordi identifikatorfeltet blir fylt frå ein annan verdi.

Vel deretter det kryptografiske snittet

Samanlikn forslaga kvar støtta klient kan tilby, og vel eit moderne snitt som gatewayen òg tillèt. Ikkje aktiver ei overdreve stor gammal liste for at éin gammal eining skal kopie til, for den lista blir standarden til gatewayen for alle som kjem etter. Skriv ned kvifor kvart gamalt alternativ framleis er der. Viss ingen kan namngje eininga som treng det, er det ikkje eit krav.

Hald IKE- og CHILD-innstillingar åtskilde i planen. Eit forslag som er akseptabelt for IKE-utvekslinga, er ikkje automatisk akseptabelt for beskytta trafikk, og dei to blir forhandla separat. Ein gateway som godtek eit forslag i eitt lag, kan framleis avvise det i det andre, og loggen vil vise ein feil som ser ut som om det første laget lukkast.

Klargjer påloggingsinformasjon gjennom ein verifisert prosess, og hald eit brukarpassord, ein delt løyndom og ein privat klientnøkkel i eigne felt. Prøving og feiling på likt namngjevne boksar er måten ein fungerande test blir ein som ikkje kan gjenskapast.

Test livssyklusen, ikkje den stabile tilstanden

For kvar klient, test den første autentiseringa, den tiltenkte applikasjonen, DNS-oppslag og dekning av adressefamiliar. Deretter øv på delane som først dukkar opp seinare: fornying, dvale og ei vanleg nettverksendring.

MOBIKE-støtte og åtferd ved reautentisering kan avvike frå det stabile resultatet du nettopp målte. Registrer hendinga og tilstanden til assosiasjonen på det tidspunktet, ikkje berre om grensesnittet til slutt ser tilkopla ut.

Definer kva direkte trafikk kan gjere medan VPN ikkje er tilgjengeleg. Det er ei policyavgjerd åtskild frå om klienten koplar til på nytt, og dei fleste utrullingane svarer på det andre spørsmålet medan dei ignorerer det første. Skriv svaret i utrullingsnotata ved sida av profilnamna. Nokon vil trenge det under ein avbrott, og dei vil ikkje ha tid til å rekonstruere det.

Bruk serveridentitetskontrollar når éin plattform er usamd

Når ein profil fungerer på éin plattform og ein annan avviser namnet, samanlikn identifikatoren klienten faktisk sende med identifikatorane sertifikatet ber. Den samanlikninga løyser dei fleste av desse sakene raskare enn å endre cipher-lister.

Oppbevar den testa matrisen saman med konfigurasjonskjelda og oppdateringsprosedyren. Når støtta for ein gammal klient sluttar, fjern unntaket med vilje i staden for å la svakare kompatibilitetsinnstillingar liggje skjult i gatewayen for neste revisjon. strongSwan sin IKEv2-dokumentasjon er ei nyttig referanse for korleis utvekslingane blir konfigurerte.