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

Проверете тунела, маршрутите и резолвера поотделно

Индикаторът „свързано“ твърди само, че връзката е вдигната. Проверете дестинацията, която всъщност ви трябва, маршрута, който я носи, и използвания резолвер, едно по едно; всяко може да е грешно, докато другите две са наред.

За неуспешен опит запишете версията на всеки компонент и очистения текст на грешката. Споделяйте тях, а не целия профил, защото профилът може да съдържа предварително споделената тайна и запазените ви идентификационни данни.

Накрая, изключете и се свържете отново, после рестартирайте веднъж. Ако профилът работи само при първия опит, проблемът е в обработката на тайни или в собствеността на маршрутите и двете са по-евтини за поправяне сега, отколкото по средата на работния ден.