Планирајте IKEv2 подешавања која одговарају више од једном клијенту
Радни профил на једној радној површини успешан је тест једног клијента. Усагласите уговор о идентитету, изаберите подржани пресек, затим тестирајте обнављање и спавање по платформи.
Радни профил на једној радној површини успешан је тест једног клијента. То није вишеплатформско распоређивање, и ако се тако третира, настаје познати образац подршке: Windows се повезује, телефон пада на провери идентитета, а управљани лаптоп се поново повезује сваки пут када се пробуди. Разлике су стварне и углавном предвидиве, зато план треба да буде матрица, а не снимак екрана.
Прво одредите уговор о идентитету
Документујте идентитет сервера, поверење у сертификат и метод аутентификације клијента пре расправе о алгоритмима. Ова три одређују може ли се клијент уопште аутентификовати, и управо их платформе изражавају различито.
Проверите како свака платформа именује очекивани идентификатор и како обрађује алтернативна имена субјекта. Профил који прихвата име сервера на једном клијенту може одбити исти сертификат на другом, јер се поље идентификатора попуњава другом вредношћу.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Затим изаберите криптографски пресек
Упоредите предлоге које сваки подржани клијент може понудити и изаберите савремени пресек који дозвољава и гејтвеј. Не укључујте превелику стару листу да би се повезао један стари уређај, јер та листа постаје подразумевана поставка гејтвеја за све који следе. Запишите зашто је свака стара опција још ту. Ако нико не може да наведе уређај коме је потребна, то није захтев.
Држите IKE и CHILD подешавања одвојена у плану. Предлог прихватљив за IKE размену није аутоматски прихватљив за заштићени саобраћај, и њих двоје се преговарају одвојено. Гејтвеј који прихвати предлог на једном слоју ипак може да га одбије на другом, а дневник ће приказати грешку која изгледа као да је први слој успео.
Обезбедите акредитиве провереним поступком и држите корисничку лозинку, заједничку тајну и приватни кључ клијента у њиховим пољима. Покушаји и грешке на кутијама сличних имена пут је којим радни тест постаје непоновљив.
Тестирајте животни циклус, а не стабилно стање
За сваки клијент тестирајте почетну аутентификацију, предвиђену апликацију, DNS резолуцију и покривеност породица адреса. Затим вежбајте делове који се појављују само касније: обнављање, спавање и нормалну промену мреже.
Подршка за MOBIKE и понашање при поновној аутентификацији могу се разликовати од стабилног резултата који сте управо измерили. Забележите догађај и стање асоцијације у том тренутку, а не само да ли интерфејс на крају изгледа повезан.
Дефинишите шта директни саобраћај сме да ради док VPN није доступан. То је одлука о политици одвојена од тога да ли ће се клијент поново повезати, и већина распоређивања одговара на друго питање игноришући прво. Запишите одговор у белешке о распоређивању поред имена профила. Неко ће га требати током прекида, и неће имати времена да га реконструише.
Користите провере идентитета сервера када се једна платформа не слаже
Када профил ради на једној платформи, а друга одбије његово име, упоредите идентификатор који је клијент заиста послао са идентификаторима које носи сертификат. То поређење решава већину таквих случајева брже од промене листа шифара.
Чувајте тестирану матрицу уз извор конфигурације и поступак ажурирања. Када се подршка за стари клијент заврши, намерно уклоните његов изузетак уместо да слабија подешавања компатибилности оставите скривена у гејтвеју за следећу ревизију. Документација strongSwan-а о IKEv2 је користан извор о томе како се конфигуришу размене.