Працоўны профіль на адным працоўным стале — гэта ўдалае выпрабаванне аднаго кліента. Гэта не міжплатформавае разгортванне, і калі ставіцца да яго як да такога, атрымліваецца знаёмая карціна падтрымкі: Windows падключаецца, тэлефон зрываецца на праверцы ідэнтычнасці, а кіраваны ноўтбук перападключаецца кожны раз, калі прачынаецца. Адрозненні рэальныя і пераважна прадказальныя, таму план павінен быць матрыцай, а не здымкам экрана.

Спачатку вызначце кантракт ідэнтычнасці

Задакументуйце ідэнтычнасць сервера, давер да сертыфіката і метад аўтэнтыфікацыі кліента перш чым абмяркоўваць алгарытмы. Гэтыя тры вызначаюць, ці можа кліент аўтэнтыфікавацца наогул, і менавіта іх платформы выяўляюць па-рознаму.

Праверце, як кожная платформа называе чаканы ідэнтыфікатар і як яна апрацоўвае альтэрнатыўныя імёны суб’екта. Профіль, які прымае імя сервера на адным кліенце, можа адхіліць той жа сертыфікат на іншым, бо поле ідэнтыфікатара запаўняецца іншым значэннем.

Contract elementWhat to decideWhere platforms diverge
Server identityName or address the client must seeIdentifier field and SAN matching
Client authenticationCertificate, EAP method or bothWhich EAP variants exist and how prompts appear
Trust anchorWhich CA and how it is deliveredStore location and provisioning path

Затым выберыце крыптаграфічнае перасячэнне

Параўнайце прапановы, якія можа прапанаваць кожны падтрымліваемы кліент, і выберыце сучаснае перасячэнне, якое таксама дазваляе шлюз. Не ўключайце празмерна вялікі спіс састарэлых варыянтаў, каб падключылася адна старая прылада, бо гэты спіс стане прадвызначэннем шлюза для ўсіх наступных. Запішыце, чаму кожны састарэлы варыянт яшчэ там. Калі ніхто не можа назваць прыладу, якой ён патрэбны, гэта не патрабаванне.

Трымайце налады IKE і CHILD рознымі ў плане. Прапанова, прымальная для абмену IKE, не аўтаматычна прымальная для абароненага трафіку, і гэтыя дзве ўзгоднены асобна. Шлюз, які прымае прапанову на адным узроўні, можа ўсё роўна адхіліць яе на іншым, і журнал пакажа збой, які выглядае так, нібы першы ўзровень атрымаўся.

Забяспечвайце ўліковыя даныя праз правераны працэс і трымайце пароль карыстальніка, агульны сакрэт і прыватны ключ кліента ў асобных палях. Спробы і памылкі на скрынях з падобнымі назвамі — гэта шлях, якім працоўнае выпрабаванне становіцца непаўторным.

Правярайце жыццёвы цыкл, а не ўстойлівы стан

Для кожнага кліента праверце пачатковую аўтэнтыфікацыю, мэтавае прыкладанне, разрозненне DNS і пакрыццё сямейства адрасоў. Затым прагоньце часткі, якія з’яўляюцца толькі пазней: абнаўленне, сон і звычайную змену сеткі.

Падтрымка MOBIKE і паводзіны пры паўторнай аўтэнтыфікацыі могуць адрознівацца ад устойлівага выніку, які вы толькі што вымералі. Запісвайце падзею і стан асацыяцыі на той момант, а не толькі тое, ці выглядае інтэрфейс у рэшце рэшт падключаным.

Вызначце, што можа рабіць прамы трафік, пакуль VPN недаступны. Гэта палітычнае рашэнне, асобнае ад таго, ці перападключыцца кліент, і большасць разгортванняў адказвае на другое пытанне, ігнаруючы першае. Запішыце адказ у нататкі разгортвання побач з імёнамі профіляў. Камусьці ён спатрэбіцца падчас збою, і ў яго не будзе часу яго аднаўляць.

Выкарыстоўвайце праверкі ідэнтычнасці сервера, калі адна платформа супярэчыць

Калі профіль працуе на адной платформе, а іншая адхіляе яго імя, параўнайце ідэнтыфікатар, які кліент фактычна адправіў, з ідэнтыфікатарамі, якія нясе сертыфікат. Такое параўнанне вырашае большасць гэтых выпадкаў хутчэй, чым змена спісаў шыфраў.

Трымайце правераную матрыцу разам з крыніцай канфігурацыі і працэдурай абнаўлення. Калі падтрымка старога кліента сканчаецца, наўмысна выдаліце яго выключэнне, замест таго каб пакідаць слабейшыя налады сумяшчальнасці схаванымі ў шлюзе для наступнага аўдыту. Дакументацыя strongSwan па IKEv2 — карысная даведка пра тое, як наладжваюцца абмены.

Падобныя артыкулы