Абмен IKEv2 працуе, потым аўтэнтыфікацыя зрываецца: дзе

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

Праверка 1: чытайце этап, а не паведамленне

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

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

Праверка 2: якая ідэнтычнасць правяралася

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

У тэрмінах strongSwan гэта rightid на кліенце, а на іншым баку — уласная ідэнтычнасць шлюза, і неадпаведнасць правальваецца яшчэ да абмеркавання EAP.

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

Праверка 3: калі задзейнічаны EAP

Кліент і сервер павінны дамовіцца пра падтрыманы метад, а бэкенд павінен прыняць прадстаўленую ідэнтычнасць.

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

Не правярайце праблемы ідэнтычнасці, адключаючы праверкі ідэнтычнасці. Гэта ператварае дыягнаставаны збой у недыягнаставаны і пакідае злучэнне слабейшым, чым было.

Праверка 4: што адбываецца пасля паспяховага ўваходу

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

Новае працоўнае злучэнне часта выяўляе праблему селектара або маршруту, якая раней была схаваная за збоем аўтэнтыфікацыі. Калі тунэль падымаецца, а праграма ўсё яшчэ не дасягае прызначэння, глядзіце на ўзгодненыя селектары і маршруты, а не зноў на ідэнтычнасць. Змена налад ідэнтычнасці ў гэты момант б’е па няправільным этапе і звычайна ламае працоўны ўваход. Пацвердзіце з дапамогай swanctl --list-sas, які паказвае дзяцей і іх селектары асобна ад IKE SA.

Праверка 5: што перадаць падтрымцы

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

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