L2TP/IPsec PSK е отказан: преминете през диалога, после през файловете

Поставяте предварително споделения ключ от съобщението на администратора в диалога на 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: някои клиенти приемат ключове по-къси от двадесет знака, а някои шлюзове налагат минимум. Ако кратък ключ бъде отказан, правилото принадлежи на сървърната политика или на валидацията на този клиент и вдигането на нещо локално няма да го промени.

Прочетете кой слой за удостоверяване се е провалил

Пуснете първо ipsec --version, защото strongSwan и Libreswan използват различни имена на файлове и синтаксис и съвет за единия може да повреди другия. После прочетете етапа на провала от съобщението на клиента или от лога на демона: оплакване за предварително споделения ключ е различно събитие от отказано потребителско име и парола.

PSK удостоверява крайните точки на тунела. Потребителското име и паролата удостоверяват човека вътре в L2TP, а PPP се занимава с тях, след като IPsec асоциацията е вдигната. Правилен PSK с грешен акаунт пак се проваля и смяната на акаунта няма да поправи ключ, който демонът никога не е прочел правилно.

Когато затваряте заявката, запишете и четирите: версия на плъгина, файла със секрети в употреба, дали ключът е въведен наново или поставен, и слоя, посочен в грешката. Тогава всеки, който повтори тази разходка, може направо да премине към разликата между работещата и провалящата се машина.