Планирајте IKEv2 поставки што одговараат на повеќе од еден клиент

Работен профил на една работна површина е успешен тест на еден клиент. Тоа не е воведување на повеќе платформи, и ако се третира како такво, се создава познатиот модел на поддршка: Windows се поврзува, телефонот не успева при проверката на идентитетот, а управуваниот преносен сметач повторно се поврзува секој пат кога ќе се разбуди. Разликите се реални и главно предвидливи, затоа планот треба да биде матрица, а не слика од екранот.

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

Пред да разговарате за алгоритми, документирајте го идентитетот на серверот, довербата во сертификатот и методот за автентикација на клиентот. Овие три одлучуваат дали клиентот воопшто може да се автентицира, и токму нив платформите ги изразуваат поинаку.

Проверете како секоја платформа го именува очекуваниот идентификатор и како ги обработува алтернативните имиња на субјектот. Профил што прифаќа име на сервер на еден клиент може да го одбие истиот сертификат на друг, бидејќи полето за идентификатор се пополнува од друга вредност.

Потоа изберете го криптографскиот пресек

Споредете ги предлозите што може да ги понуди секој поддржан клиент и изберете современ пресек што го дозволува и портата. Не активирајте преголема стара листа за да се поврзе еден стар уред, бидејќи таа листа станува стандардна поставка на портата за сите што следат. Запишете зошто секоја стара опција се уште е таму. Ако никој не може да го именува уредот на кој му е потребна, тоа не е барање.

Држете ги IKE и CHILD поставките одвоени во планот. Предлог прифатлив за размената IKE не е автоматски прифатлив за заштитениот сообраќај, и двете се преговараат одделно. Порта што прифаќа предлог на еден слој сепак може да го одбие на другиот, и дневникот ќе покаже грешка што изгледа како првиот слој да успеал.

Обезбедете акредитиви преку проверен процес и држете ја корисничката лозинка, заедничката тајна и приватниот клуч на клиентот во нивни полиња. Обидите и грешките на кутии со слични имиња се патот по кој работниот тест станува неповторлив.

Тестирајте го животниот циклус, а не стабилната состојба

За секој клиент тестирајте ја почетната автентикација, предвидената апликација, DNS резолуцијата и покриеноста на адресните семејства. Потоа вежбајте ги деловите што се појавуваат само подоцна: обновување, спиење и нормална промена на мрежата.

Поддршката за MOBIKE и однесувањето при повторна автентикација може да се разликуваат од стабилниот резултат што штотуку го измеривте. Забележете го настанот и состојбата на асоцијацијата во тој момент, а не само дали интерфејсот на крајот изгледа поврзан.

Определете што смее да прави директниот сообраќај додека VPN не е достапен. Тоа е одлука за политика одвоена од тоа дали клиентот повторно ќе се поврзе, и повеќето воведувања одговараат на второто прашање додека го игнорираат првото. Запишете го одговорот во белешките за воведување до имињата на профилите. Некој ќе го бара за време на прекин, и нема да има време да го реконструира.

Користете проверки на идентитетот на серверот кога една платформа не се согласува

Кога профил работи на една платформа, а друга го одбива неговото име, споредете го идентификаторот што клиентот навистина го испратил со идентификаторите што ги носи сертификатот. Оваа споредба ги решава повеќето од овие случаи побрзо отколку менување на листите со шифри.

Чувајте ја тестираната матрица заедно со изворот на конфигурацијата и постапката за ажурирање. Кога поддршката за стар клиент ќе заврши, намерно отстранете го неговиот исклучок, наместо да оставите послаби поставки за компатибилност скриени во портата за следната ревизија. Документацијата на strongSwan за IKEv2 е корисна референца за тоа како се конфигурираат размените.