Дзве асобы ў адным уваходзе IKEv2: спачатку машына, потым карыстальнік

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

Сімптом: збой пасля паспяховага першага доказу

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

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

Што дадае пашырэнне і чаго не дадае

IKEv2 нясе пашырэнне для некалькіх абменаў аўтэнтыфікацыі ў адной сесіі. RFC 4739 апісвае, сярод іншых паслядоўнасцей, кліента, які даказвае асобу па сертыфікаце, а потым аўтэнтыфікуе чалавека праз EAP. Дакумент мае статус Experimental, гэта значыць ніводная рэалізацыя вам гэтай магчымасці не вінаватая. Не меркавайце нічога пра падтрымку, пакуль суразмоўца не ўзгодніць яе.

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

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

EAP-TLS — трэцяя форма, і яна таксама не гэтая. Там кліенцкі сертыфікат прад'яўляецца ўнутры метаду EAP, таму кліент усё ж завяршае адну аўтэнтыфікацыю IKE. Уліковыя даныя могуць выглядаць ідэнтычна выпадку з некалькімі раўндамі, хаця пратакол нясе адзін раўнд замест двух. Таму праект, скапіяваны з разгортвання EAP-TLS, зрываецца ў той момант, дзе чакаецца другі доказ.

Той жа файл на шлюзе чытаецца інакш

Той жа файл swanctl чытаецца па-рознаму ў залежнасці ад таго, дзе ён выконваецца, і менавіта гэта збівае людзей з панталыку. На ноўтбуку шлюз з'яўляецца суразмоўцам, а на шлюзе суразмоўцам з'яўляецца ноўтбук, таму запісвайце бок local як «хто я», а бок remote як «каго я прыму». Блок local апісвае, як гэты канец аўтэнтыфікуе сябе, а блок remote указвае, што ён патрабуе ад другога боку. Капіраванне блока паміж двума файламі перавяртае яго сэнс, не змяняючы ніводнага знака. Параўнанне двух файлаў не кажа амаль нічога, бо адны і тыя ж словы ў кожным з іх азначаюць процілеглае.

Месца раздзела задае яго парадак, калі нумар раўнда не перакрывае яго. Таму дадатковыя раздзелы local або remote апісваюць дадатковыя раўнды, а не альтэрнатывы, і відавочны нумар раўнда ў даведніку swanctl.conf існуе менавіта для таго, каб гэты парадак быў свядомым. Без яго перамяшчэнне блока змяняе паводзіны. Таму дзве канфігурацыі, якія на паперы выглядаюць раўназначнымі, могуць працаваць у процілеглым парадку.

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

Адрознівайце раўнды ад незалежных фактараў

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

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

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

Запішыце правіла спалучэння і праверце адмовы

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

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

swanctl --list-conns
swanctl --list-sas

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