Planifikoni cilësime IKEv2 që u përshtaten më shumë se një klienti

Një profil që funksionon në një desktop është një test i suksesshëm i një klienti të vetëm. Nuk është një vendosje ndër-platformë, dhe trajtimi si i tillë prodhon modelin e njohur të mbështetjes: Windows lidhet, telefoni dështon në kontrollin e identitetit dhe laptopi i administruar rilidhet sa herë zgjohet. Dallimet janë reale dhe kryesisht të parashikueshme, prandaj plani duhet të jetë një matricë dhe jo një pamje ekrani.

Së pari vendosni kontratën e identitetit

Dokumentoni identitetin e serverit, besimin në certifikatë dhe metodën e vërtetimit të klientit përpara se të diskutoni algoritmet. Këto të treja vendosin nëse një klient mund të vërtetohet fare, dhe janë pjesët që platformat i shprehin ndryshe.

Kontrolloni si e emërton secila platformë identifikuesin e pritur dhe si trajton emrat alternativë të subjektit. Një profil që pranon një emër serveri në një klient mund të refuzojë të njëjtën certifikatë në një tjetër, sepse fusha e identifikuesit mbushet nga një vlerë tjetër.

Më pas zgjidhni kryqëzimin kriptografik

Krahasoni propozimet që mund të ofrojë secili klient i mbështetur dhe zgjidhni një kryqëzim modern që e lejon edhe porta. Mos aktivizoni një listë të madhe të vjetër që një pajisje e vjetër të lidhet, sepse ajo listë bëhet parazgjedhja e portës për të gjithë ata që vijnë më pas. Shkruani pse çdo opsion i vjetër është ende aty. Nëse askush nuk mund të emërtojë pajisjen që ka nevojë për të, nuk është kërkesë.

Mbani cilësimet IKE dhe CHILD të ndara në plan. Një propozim i pranueshëm për shkëmbimin IKE nuk është automatikisht i pranueshëm për trafikun e mbrojtur, dhe të dyja negociohen veçmas. Një portë që pranon një propozim në një shtresë mund ta refuzojë atë në tjetrën, dhe regjistri do të tregojë një dështim që duket sikur shtresa e parë ka pasur sukses.

Siguroni kredencialet përmes një procesi të verifikuar dhe mbani fjalëkalimin e përdoruesit, sekretin e përbashkët dhe çelësin privat të klientit në fushat e tyre. Provat dhe gabimet në kuti me emra të ngjashëm janë mënyra se si një test që funksionon bëhet i pareprodushëm.

Testoni ciklin e jetës, jo gjendjen e qëndrueshme

Për çdo klient, testoni vërtetimin fillestar, aplikacionin e synuar, zgjidhjen e DNS-së dhe mbulimin e familjeve të adresave. Pastaj ushtroni pjesët që shfaqen vetëm më vonë: rinovimi, gjumi dhe një ndryshim normal i rrjetit.

Mbështetja për MOBIKE dhe sjellja e rivërtetimit mund të ndryshojnë nga rezultati i qëndrueshëm që sapo matët. Regjistroni ngjarjen dhe gjendjen e asociimit në atë moment, jo vetëm nëse ndërfaqja në fund duket e lidhur.

Përcaktoni çfarë mund të bëjë trafiku i drejtpërdrejtë ndërsa VPN nuk është i disponueshëm. Ky është një vendim politikash i ndarë nga pyetja nëse klienti rilidhet, dhe shumica e vendosjeve i përgjigjen pyetjes së dytë duke injoruar të parën. Shkruani përgjigjen në shënimet e vendosjes pranë emrave të profileve. Dikush do t'i ketë nevojë gjatë një ndërprerjeje dhe nuk do të ketë kohë ta rindërtojë.

Përdorni kontrolle të identitetit të serverit kur një platformë nuk pajtohet

Kur një profil funksionon në një platformë dhe një tjetër refuzon emrin e tij, krahasoni identifikuesin që klienti ka dërguar në të vërtetë me identifikuesit që mban certifikata. Ky krahasim zgjidh shumicën e këtyre rasteve më shpejt sesa ndryshimi i listave të shifrave.

Ruani matricën e testuar së bashku me burimin e konfigurimit dhe procedurën e përditësimit. Kur përfundon mbështetja për një klient të vjetër, hiqni me qëllim përjashtimin e tij në vend që të lini cilësime më të dobëta përputhshmërie të fshehura në portë për auditimin e radhës. Dokumentacioni i strongSwan për IKEv2 është një referencë e dobishme për mënyrën se si konfigurohen shkëmbimet.