Планирайте настройки на IKEv2, които да пасват на повече от един клиент

Работещ профил на един настолен компютър е успешен тест на един клиент. Това не е междуплатформено внедряване и третирането му като такова води до познатия модел на поддръжка: Windows се свързва, телефонът се проваля при проверката на идентичността, а управляваният лаптоп се свързва наново всеки път, когато се събуди. Разликите са реални и до голяма степен предвидими, затова планът трябва да е матрица, а не екранна снимка.

Първо определете договора за идентичност

Документирайте идентичността на сървъра, доверието към сертификата и метода за удостоверяване на клиента, преди да обсъждате алгоритми. Тези три решават дали клиентът може изобщо да се удостовери, и те са частите, които платформите изразяват по различен начин.

Проверете как всяка платформа именува очаквания идентификатор и как обработва алтернативните имена на субекта. Профил, който приема име на сървър на един клиент, може да отхвърли същия сертификат на друг, защото полето за идентификатор се попълва от друга стойност.

След това изберете криптографското сечение

Сравнете предложенията, които всеки поддържан клиент може да предложи, и изберете модерно сечение, което шлюзът също разрешава. Не включвайте прекалено голям списък със стари опции, за да се свърже едно старо устройство, защото този списък става подразбиране на шлюза за всички следващи. Запишете защо всяка стара опция още е там. Ако никой не може да назове устройството, което има нужда от нея, тя не е изискване.

Дръжте настройките на IKE и CHILD отделни в плана. Предложение, което е приемливо за обмена IKE, не е автоматично приемливо за защитения трафик и двете се договарят отделно. Шлюз, който приема предложение на едно ниво, все още може да го отхвърли на друго и журналът ще покаже отказ, който изглежда сякаш първото ниво е успяло.

Осигурете идентификационни данни чрез проверен процес и дръжте потребителската парола, споделената тайна и частния ключ на клиента в отделни полета. Пробите и грешките върху еднакво именувани кутии са начинът, по който работещ тест става невъзпроизводим.

Тествайте жизнения цикъл, а не устойчивото състояние

За всеки клиент тествайте първоначалното удостоверяване, предвиденото приложение, DNS разрешаването и покритието на адресните семейства. След това упражнете частите, които се появяват само по-късно: подновяване, сън и нормална промяна на мрежата.

Поддръжката на MOBIKE и поведението при повторно удостоверяване може да се различават от устойчивия резултат, който току-що измерихте. Записвайте събитието и състоянието на асоциацията към онзи момент, а не само дали интерфейсът в крайна сметка изглежда свързан.

Определете какво може да прави директният трафик, докато VPN е недостъпен. Това е политическо решение, отделно от това дали клиентът ще се свърже отново, и повечето внедрявания отговарят на втория въпрос, като игнорират първия. Запишете отговора в бележките за внедряване до имената на профилите. Някой ще има нужда от него по време на прекъсване и няма да има време да го възстанови.

Използвайте проверки на идентичността на сървъра, когато една платформа не е съгласна

Когато профил работи на една платформа, а друга отхвърля името му, сравнете идентификатора, който клиентът действително е изпратил, с идентификаторите, които носи сертификатът. Това сравнение решава повечето от тези случаи по-бързо от смяната на списъци с шифри.

Пазете тестваната матрица заедно с източника на конфигурацията и процедурата за актуализация. Когато поддръжката за стар клиент приключи, премахнете изключението му умишлено, вместо да оставяте по-слаби настройки за съвместимост, скрити в шлюза за следващия одит. Документацията на strongSwan за IKEv2 е полезна справка за това как се конфигурират обмените.