IKEv2-instellingen plannen die bij meer dan één client passen

Een werkend profiel op één desktop is een geslaagde test van één client. Het is geen platformoverschrijdende uitrol, en als je het zo behandelt, krijg je het bekende ondersteuningspatroon: Windows maakt verbinding, de telefoon faalt bij de identiteitscontrole en de beheerde laptop maakt bij elk ontwaken opnieuw verbinding. De verschillen zijn echt en grotendeels voorspelbaar, daarom moet het plan een matrix zijn en geen schermafbeelding.

Bepaal eerst het identiteitscontract

Documenteer de serveridentiteit, het vertrouwen in het certificaat en de methode voor clientauthenticatie voordat je over algoritmen praat. Die drie bepalen of een client überhaupt kan authenticeren, en het zijn de onderdelen die platforms anders uitdrukken.

Controleer hoe elk platform de verwachte identifier benoemt en hoe het alternatieve subjectnamen behandelt. Een profiel dat een servernaam op de ene client accepteert, kan hetzelfde certificaat op een andere weigeren omdat het identifierveld uit een andere waarde wordt gevuld.

Kies daarna de cryptografische doorsnede

Vergelijk de voorstellen die elke ondersteunde client kan bieden en kies een moderne doorsnede die de gateway ook toestaat. Schakel geen overdreven grote oude lijst in zodat één oud apparaat verbinding maakt, want die lijst wordt de standaard van de gateway voor iedereen die volgt. Schrijf op waarom elke oude optie er nog is. Als niemand het apparaat kan noemen dat die nodig heeft, is het geen vereiste.

Houd IKE- en CHILD-instellingen gescheiden in het plan. Een voorstel dat aanvaardbaar is voor de IKE-uitwisseling, is niet automatisch aanvaardbaar voor beveiligd verkeer, en de twee worden apart onderhandeld. Een gateway die een voorstel in de ene laag accepteert, kan het in de andere nog weigeren, en het log zal een fout tonen die lijkt alsof de eerste laag is geslaagd.

Lever inloggegevens via een geverifieerd proces en houd een gebruikerswachtwoord, een gedeeld geheim en een privésleutel van de client in hun eigen velden. Vallen en opstaan op gelijknamige dozen is de manier waarop een werkende test er een wordt die niet reproduceerbaar is.

Test de levenscyclus, niet de stabiele toestand

Test voor elke client de eerste authenticatie, de bedoelde toepassing, DNS-resolutie en dekking van adresfamilies. Oefen daarna de delen die pas later verschijnen: verlenging, slaap en een normale netwerkwijziging.

MOBIKE-ondersteuning en gedrag bij herauthenticatie kunnen afwijken van het stabiele resultaat dat je net hebt gemeten. Leg de gebeurtenis en de status van de associatie op dat moment vast, niet alleen of de interface uiteindelijk verbonden lijkt.

Bepaal wat direct verkeer mag doen terwijl de VPN niet beschikbaar is. Dat is een beleidsbeslissing los van of de client opnieuw verbinding maakt, en de meeste uitrollingen beantwoorden de tweede vraag terwijl ze de eerste negeren. Schrijf het antwoord in de uitrolnotities naast de profielnamen. Iemand zal het tijdens een storing nodig hebben en geen tijd hebben om het te reconstrueren.

Gebruik serveridentiteitscontroles wanneer één platform het oneens is

Wanneer een profiel op het ene platform werkt en een ander de naam weigert, vergelijk dan de identifier die de client werkelijk heeft verzonden met de identifiers die het certificaat draagt. Die vergelijking lost de meeste van deze gevallen sneller op dan het wijzigen van cijferlijsten.

Bewaar de geteste matrix samen met de configuratiebron en de updateprocedure. Wanneer de ondersteuning voor een oude client eindigt, verwijder de uitzondering dan bewust in plaats van zwakkere compatibiliteitsinstellingen verborgen in de gateway achter te laten voor de volgende audit. De strongSwan-documentatie over IKEv2 is een nuttige referentie voor hoe de uitwisselingen worden geconfigureerd.