Той самий .ovpn файл підключається з оболонки й завершується за тайм-аутом після імпорту в NetworkManager. Природний висновок — VPN зламано. Імовірніше пояснення менше: NetworkManager не зберіг файл, він імпортував частину його у збережене з'єднання, а робочий тунель натомість використовує ці збережені дані. Те, що файл каже зараз, не стосується того, що містить профіль.

Файл — це не профіль

Імпорт — це переклад, а не монтування. Параметри, які розуміє плагін, стають ключами в vpn.data словнику з'єднання; параметри, які він не розуміє, відкидаються або записуються в іншому місці, а початковий шлях — лише посилання. Подальше редагування вихідного файлу нічого не змінює в уже збереженому з'єднанні.

Ця прогалина пояснює цілу родину звітів: спільний ключ повернули, файл оновили, а тунель усе одно не працює. Збережений профіль досі вказує на старий шлях або старе значення, і командний рядок продовжує працювати, бо читає файл, який ви відредагували. Два клієнти, два джерела істини, і оновлено лише одне з них.

Читайте збережений профіль, а не діалог

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

Використовуйте UUID, коли два профілі мають однакову назву, і переконайтеся, що тип служби — очікуваний OpenVPN плагін, а не інший тип VPN, який випадково встановлено. Потім порівняйте кінцеву точку, транспорт і посилання на сертифікати з робочим викликом.

Значення, видиме в графічному редакторі, не доводить, що його збережено. Збережіть, відкрийте знову й прочитайте його назад через командний рядок; історичні дефекти збереження — причина перевірити збережені дані, а не доказ того, що кожна поточна збірка має ту саму помилку. Перевірка коштує однієї команди.

Два ключі й напрямок, що має значення

Для з'єднання з автентифікацією TLS плагін зберігає шлях до спільного ключа в ta і напрямок у ta-dir, якщо розгортання використовує напрямок. Обидва живуть у словнику даних профілю, і обидва мають відповідати тому, що очікує сервер.

Напрямок — це рішення на боці сервера, виражене на клієнті. Вибрати один тому, що він є в сусідньому профілі, — це шлях, яким робочий ключ починає провалювати рукостискання. Якщо конфігурація сервера без напрямку, клієнт не повинен вигадувати напрямок.

Сам файл ключа має бути читабельним для плагіна в тому контексті, у якому він справді працює. Обмежений пакет має інший погляд на файлову систему, ніж звичайна настільна інсталяція, тому шлях, що існує у вашій оболонці, може бути невидимим для служби.

Оновіть один запис, а не словник

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

Провідний плюс оновлює окремі записи словника. Присвоєння vpn.data без нього замінює весь словник, і саме так один відсутній ключ перетворюється на п'ять зламаних налаштувань. Перечитайте профіль після зміни й переконайтеся, що інші записи вижили. Словник, який втратив віддалену кінцеву точку й сертифікати, — це значно довший вечір, ніж той, з якого ви почали.

Перепідключіться через звичайні елементи керування й спостерігайте за етапом, який не проходить. Якщо шлюз спільного ключа тепер пройдено й клієнт повідомляє про помилку сертифіката або автентифікації користувача, ви просунулися вперед, і наступне розслідування інше.

Не змішуйте режими каналу керування

tls-auth, tls-crypt, і tls-crypt-v2 — різні схеми. Схожий файл ключа не робить їх взаємозамінними, а заповнення полів TLS-Auth тому, що в іншому профілі є відформатований ключ, створює профіль, який не проходить так, як за неправильного ключа.

Використовуйте зіставлення плагіна, що відповідає режиму в конфігурації сервера. Якщо режим неясний, запитайте власника сервера, а не вгадуйте з першого рядка файлу.

Зберігайте шлях відновлення, коли тунель несе вашу сесію керування. Збережена зміна не обов'язково застосована зміна, а успішний імпорт не доводить, що кожен вихідний параметр підтримувався. Обидві ці прогалини варто знати перед тим, як перепідключити ланку, через яку ви працюєте.

Схожі статті