Beplan IKEv2-instellings wat by meer as een kliënt pas

’n Werkende profiel op een lessenaar is ’n suksesvolle toets van een kliënt. Dit is nie ’n platformoorkoepelende ontplooiing nie, en om dit as een te behandel lewer die bekende ondersteuningspatroon op: Windows verbind, die selfoon faal by die identiteitskontrole, en die bestuurde skootrekenaar herverbind elke keer wanneer dit wakker word. Die verskille is werklik en meestal voorspelbaar, en daarom moet die plan ’n matriks wees eerder as ’n skermskoot.

Bepaal eers die identiteitskontrak

Dokumenteer die bedieneridentiteit, die sertifikaatvertroue en die kliëntverifikasiemetode voordat algoritmes bespreek word. Daardie drie bepaal of ’n kliënt hoegenaamd kan verifieer, en hulle is die dele wat platforms anders uitdruk.

Kontroleer hoe elke platform die verwagte identifiseerder benoem en hoe dit alternatiewe subjekname hanteer. ’n Profiel wat ’n bedienernaam op een kliënt aanvaar, kan dieselfde sertifikaat op ’n ander verwerp omdat die identifiseerderveld uit ’n ander waarde gevul word.

Kies dan die kriptografiese gemeenskaplike deel

Vergelyk die voorstelle wat elke ondersteunde kliënt kan bied en kies ’n moderne gemeenskaplike deel wat die deurgang ook toelaat. Moet nie ’n oorgroot ou lys aktiveer sodat een ou toestel kan verbind nie, want daardie lys word die deurgang se verstek vir almal wat volg. Skryf neer waarom elke ou opsie nog daar is. As niemand die toestel kan noem wat dit nodig het nie, is dit nie ’n vereiste nie.

Hou IKE- en CHILD-instellings apart in die plan. ’n Voorstel wat vir die IKE-uitruiling aanvaarbaar is, is nie outomaties aanvaarbaar vir beskermde verkeer nie, en die twee word afsonderlik onderhandel. ’n Deurgang wat ’n voorstel op een laag aanvaar, kan dit steeds op die ander weier, en die log sal ’n faling wys wat lyk asof die eerste laag geslaag het.

Voorsien geloofsbriewe deur ’n geverifieerde proses, en hou ’n gebruikerswagwoord, ’n gedeelde geheim en ’n kliënt se private sleutel in hul eie velde. Probeer-en-tref oor soortgelyk benoemde bokse is hoe ’n werkende toets een word wat nie herhaal kan word nie.

Toets die lewensiklus, nie die bestendige toestand nie

Toets vir elke kliënt die aanvanklike verifikasie, die beoogde toepassing, DNS-resolusie en dekking van adresfamilies. Oefen dan die dele wat eers later verskyn: hernuwing, slaap en ’n normale netwerkverandering.

MOBIKE-ondersteuning en herautentikasiegedrag kan verskil van die bestendige resultaat wat jy pas gemeet het. Teken die gebeurtenis en die assosiasietoestand op daardie oomblik aan, nie net of die koppelvlak uiteindelik verbind lyk nie.

Bepaal wat direkte verkeer mag doen terwyl die VPN onbeskikbaar is. Dit is ’n beleidsbesluit apart van of die kliënt herverbind, en die meeste ontplooiings beantwoord die tweede vraag terwyl hulle die eerste ignoreer. Skryf die antwoord in die ontplooiingsnotas langs die profielname. Iemand sal dit tydens ’n onderbreking nodig hê, en hulle sal nie tyd hê om dit te herkonstrueer nie.

Gebruik bedieneridentiteitskontroles wanneer een platform verskil

Wanneer ’n profiel op een platform werk en ’n ander verwerp sy naam, vergelyk die identifiseerder wat die kliënt werklik gestuur het met die identifiseerders wat die sertifikaat dra. Daardie vergelyking los die meeste van hierdie gevalle vinniger op as om syferlyste te verander.

Hou die getoetsde matriks saam met die konfigurasiebron en die opdateringsprosedure. Wanneer ondersteuning vir ’n ou kliënt eindig, verwyder sy uitsondering doelbewus eerder as om swakker versoenbaarheidsinstellings in die deurgang te laat wegkruip vir die volgende oudit om te vind. Die strongSwan IKEv2-dokumentasie is ’n nuttige verwysing vir hoe die uitruilings gekonfigureer word.