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

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

Пачніце з дыялогу, але не давярайце полю

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

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

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

Прасачыце ключ унутр /etc/ipsec.d

Плагін ніколі не перадае PSK дэману IPsec як аргумент у камандным радку. Замест гэтага ён захоўвае значэнне ў файле сакрэтаў і ладзіць так, каб дэман падхапіў гэты файл, дадаючы радок include у /etc/ipsec.secrets, калі яго няма. Тое, што трымае дыялог, гэта ўваход для згенераванага файла, а не значэнне, якое выкарыстоўваецца.

Пералічыце, што ёсць, перш чым нешта змяняць:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Старыя выпускі плагіна пісалі па адным файле на злучэнне, названым па UUID злучэння, напрыклад /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Выдаленне профілю ў аплеце не выдаляе гэты файл надзейна. Калі стары файл ад папярэдняга сервера ўсё яшчэ на дыску і ўсё яшчэ ўключаны, дэман можа выбраць сакрэт, які належыць профілю, якім вы больш не карыстаецеся, і злучэнне падае, хоць бачнае поле правільнае.

Зразумейце, што змена 1.2.12 зрабіла з абнаўленнямі

Версія плагіна 1.2.12 замяніла файлы сакрэтаў для кожнага злучэння адным агульным файлам, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Абнаўленне не прыбірае старыя файлы па UUID, а існы радок include /etc/ipsec.d/*.secrets усё яшчэ іх уключае. Версія 1.2.16 змяніла апрацоўку прапаноў па змаўчанні, а не раскладку сакрэтаў.

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

Аддзяліце сімвалы, якія фармат захоўвання не можа ўтрымаць

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

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

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

Прачытайце, які ўзровень аўтэнтыфікацыі збавiў

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

PSK аўтэнтыфікуе канчатковыя пункты тунэля. Імя карыстальніка і пароль аўтэнтыфікуюць чалавека ўнутры L2TP, і PPP займаецца імі пасля таго, як асацыяцыя IPsec паднялася. Правільны PSK з няправільным уліковым запісам усё роўна падае, і змена ўліковага запісу не адрамантуе ключ, які дэман ніколі не прачытаў правільна.

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

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