SSTP у Linux не працює до входу? Перевірте компоненти виконання

Ви встановлюєте плагін SSTP, перемикач з'являється в редакторі мережі, ви вводите шлюз і ім'я користувача, і профіль відмовляє із загальною помилкою ще до запиту пароля. У цій послідовності немає нічого незвичайного, і ніщо в ній не доводить, що програмне забезпечення тунелю встановлено. З'єднання SSTP збирається з частин, які постачаються окремо: плагін VPN, який NetworkManager може запустити, клієнтська програма SSTP, що володіє сеансом TLS і PPP, демон PPP під нею та сховище секретів, яке з'єднанню дозволено читати.

Що додає пункт меню, а що ні

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

Далі клієнту потрібен PPP, бо SSTP переносить сеанс PPP усередині з'єднання TLS. Без pppd тунель може завершити рукостискання TLS і все одно загинути на першому керуючому кадрі, що виглядає як проблема облікових даних і нею не є. У Debian і Ubuntu частини надходять як network-manager-sstp, sstp-client і ppp, і встановлення лише першої — найпоширеніша причина того, що форма приймає всі поля, а з'єднання так і не встановлюється.

Вибір робочого столу додає ще один поділ. Plasma редагує профілі через plasma-nm, якому потрібен власний компонент SSTP і який читає той самий опис служби, тому редактор без пункту SSTP і CLI, що добре створює профілі, — це відсутня половина редактора, а не зламане середовище виконання.

Прочитайте перший невдалий етап, перш ніж щось перевстановлювати

Невдала спроба SSTP проходить етапи у фіксованому порядку, і етап, що не вдався, підказує, на який компонент дивитися.

Запуск плагіна — перший, і збій там дає повідомлення про службу VPN, а не про сервер. Далі йде TCP-з'єднання до порту 443; відмова або тайм-аут тут — проблема доступності, а не TLS. Потім рукостискання TLS і перевірка автентичності сервера, далі узгодження PPP і автентифікація облікового запису, і нарешті призначення адрес і маршрути. Спостерігайте за journalctl -f -u NetworkManager, коли активуєте профіль один раз, і читайте перший конкретний рядок, а не останній загальний.

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

Довіра до сертифіката і вхід в обліковий запис — окремі ворота

Рукостискання перевіряє, що сервер — той, до якого ви хотіли потрапити, за налаштованими видавцем і іменем. Лише після цього шар PPP пропонує ваше ім'я користувача й пароль методу автентифікації шлюзу. Отже, дві незалежні перевірки оцінюються у фіксованому порядку, з окремими налаштуваннями для кожної. Ніщо введене в поле пароля не може вплинути на першу.

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

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

Нехай один власник тримає профіль і секрети

Коли профіль існує, активуйте його через NetworkManager і дозвольте цьому менеджеру володіти отриманими маршрутами та змінами розв'язувача. Запуск другого самостійного клієнта SSTP, коли NetworkManager уже веде з'єднання, дає два набори маршрутів, дві конфігурації DNS і сеанс налагодження без єдиного джерела істини.

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

Перевірте тунель, маршрути й розв'язувач окремо

Індикатор «підключено» стверджує лише, що з'єднання піднялося. Перевірте ціль, яка вам справді потрібна, маршрут, що її несе, і використовуваний розв'язувач, по одному; кожен може бути неправильним, поки два інші гаразд.

Для невдалої спроби збережіть версію кожного компонента й очищений текст помилки. Діліться ними, а не повним профілем, бо профіль може містити наперед спільний секрет і ваші збережені облікові дані.

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