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 е најбрзиот тест, бидејќи барањето што никогаш не се појавува ви кажува дека агентот веќе немал што да понуди.

Проверете ги тунелот, рутите и резолверот одделно

Показателот за поврзано тврди само дека врската се крена. Проверете ја дестинацијата што навистина ви треба, рутата што ја носи и резолверот што се користи, едно по едно; секое може да е погрешно додека другите две се во ред.

За неуспешен обид, забележете ја верзијата на секој компонент и исчистениот текст на грешката. Споделете ги нив, не целиот профил, бидејќи профилот може да ја содржи однапред споделената тајна и вашите зачувани акредитиви.

На крај, исклучете се и поврзете се повторно, потоа рестартирајте еднаш. Ако профилот работи само при првиот обид, проблемот е во ракувањето со тајни или во сопственоста на рутите, и двете се поевтини за поправка сега отколку среде работен ден.