Ці можа адзін VPN-сэрвіс абслугоўваць дэсктопы Windows, Mac і Linux?

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

Пачніце з кантракта доступу, а не з кліенцкага файла

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

Прыклад офіса робіць форму канкрэтнай: серверы праграм у 10.60.0.0/16, прыватныя імёны пад corp.example, унутраны рэзалвер на 10.61.0.53 і звычайны прагляд, пакінуты на тым шляху, які прылада ўжо выкарыстоўвае. Апошні пункт — гэта рашэнне палітыкі, а не значэнне па змаўчанні кліента, і некаторыя кліенты адправяць усё праз тунель, калі ніхто не скажа інакш. Запішыце кантракт з датай і ўладальнікам, бо менавіта гэты запіс пазней пакажа, ці змяніўся тунель, ці палітыка.

Выбераце адзін пратакол і адну пару аўтэнтыфікацыі, якую вы можаце абараніць

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

Праверце пару на кожнай мэтавай платформе да напісання кіраўніцтва па разгортванні, а не пасля. Шлюз, які прапануе і EAP-MSCHAPv2, і EAP-TLS, дае вам месца для адкату, пры ўмове, што адкат задокументаваны як падтрымліваемы, а не выяўлены падчас інцыдэнту. Два падтрымліваемыя шляхі — таннае страхаванне; незадакументаваны трэці шлях — будучы тыкет.

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

Пабудуйце адзін артэфакт на кожную платформу з кантракта

Windows бярэ профіль VPNv2, дастаўлены праз MDM або створаны лакальна з Add-VpnConnection і яго XML-нагрузкай. Балючыя часткі — гэта абсяг і давер. Профіль з абсягам прылады і профіль з абсягам карыстальніка ўсталёўваюцца ў розныя сховішчы, таму сертыфікат, патрэбны кліенту, павінен знаходзіцца ў сховішчы, якое адпавядае абранаму абсягу. Памылка ў гэтай пары дае профіль, які чыста імпартуецца, а затым збаўляе на першым злучэнні.

macOS бярэ профіль канфігурацыі з кіраванай нагрузкай VPN, падпісаны і адпраўлены праз MDM або ўсталяваны ўручную для пілота. Ідэнтычнасць і ланцужок CA ідуць асобнымі нагрузкамі, таму профіль можа ўсталявацца без скаргаў і ўсё ж збавіць у момант злучэння. Праверце спіс нагрузак, а не толькі вынік усталявання.

Linux залежыць ад бэкенда за NetworkManager, а strongSwan і плагін NetworkManager — асобныя пакеты. Уласцівасці злучэння залежаць ад плагіна, а не з’яўляюцца агульнымі ключамі VPN, таму ключ, скапіраваны з іншага плагіна, часта захоўваецца без памылкі, а затым збаўляе пры актывацыі. Пабудуйце злучэнне на чыстым вобразе, каб пацвердзіць, што плагін ёсць там, дзе ён сапраўды будзе працаваць.

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

Праверце маршруты, рэзалвер і перападключэнне на чыстым уліковым запісе

Падключэнне — не прыёмачны тэст. У Windows Get-VpnConnection паказвае профіль, а route print паказвае, ці трапіў прыватны прэфікс на інтэрфейс тунеля. У macOS scutil --nc list пацвярджае актыўны сэрвіс, а scutil --dns паказвае парадак рэзалвера, які сістэма сапраўды выкарыстае.

У Linux nmcli connection show --active даказвае, што злучэнне ўзнята, а resolvectl status паказвае DNS для кожнага канала. Рэзалвер, прысутны ў файле злучэння, але адсутны ў вывадзе па кожным канале, азначае, што раздзелены DNS не ўжываецца. Гэта розніца паміж імёнамі, якія рэзалвяцца, і імёнамі, якія рэзалвяцца праз тунель, і яна змяняе, якая каманда падтрымкі бярэ наступны крок. Параўнайце вывад па кожным канале да і пасля ўзняцця злучэння, а не толькі пасля.

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

Версіянуйце пакет і трымайце шлях адкату

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

Трымайце папярэдні пакет для кожнай платформы даступным і запішыце побач каманду яго выдалення. Выдаленне профілю VPN — не люстраная выява яго ўсталявання ў Windows, macOS ці Linux, і адрозненні ўсплываюць у самы нязручны момант. Прарэпетыруйце выдаленне аднойчы на запасной прыладзе, каб архіў стаў планам, а не надзеяй.