SSTP på Linux feiler før innlogging? Sjekk kjøretidsdelene

Du installerer SSTP-tillegget, radioknappen dukker opp i nettverkseditoren, du fyller inn en gateway og et brukernavn, og profilen feiler med en generisk feil før den i det hele tatt spør om et passord. Ingenting ved den sekvensen er uvanlig, og ingenting i den beviser at tunnelprogramvaren er installert. En SSTP-tilkobling settes sammen av deler som leveres separat: et VPN-tillegg som NetworkManager kan starte, SSTP-klientprogrammet som eier TLS- og PPP-økten, PPP-demonen under det, og et hemmelighetslager som tilkoblingen har lov til å lese.

Hva menypunktet tilfører, og hva det ikke gjør

Tillegget bidrar med en tjenestebeskrivelse som forteller NetworkManager hvordan det skal startes, og på de fleste distribusjoner en liten editor som tegner skjemaet. Det er hele omfanget av menypunktet. Klientprogrammet kommer fra en annen kildekodepakke, og tilleggets egen README sier delingen rett ut: det er et tillegg, ikke en klient.

Klienten trenger deretter PPP, fordi SSTP bærer en PPP-økt inne i en TLS-tilkobling. Uten pppd kan tunnelen fullføre TLS-håndtrykket og likevel dø ved den første kontrollrammen, noe som ser ut som et problem med påloggingsinformasjon og ikke er det. På Debian og Ubuntu kommer delene som network-manager-sstp, sstp-client og ppp, og å installere bare den første er den vanligste grunnen til at et skjema godtar hvert felt mens tilkoblingen aldri fullføres.

Valget av skrivebord legger til en deling til. Plasma redigerer profiler via plasma-nm, som trenger sin egen SSTP-komponent og leser den samme tjenestebeskrivelsen, så en editor uten SSTP-punkt og en CLI som lager profiler fint, er en manglende halvdel av editoren, ikke en ødelagt kjøretid.

Les den første feilende fasen før du installerer noe på nytt

Et mislykket SSTP-forsøk går gjennom faser i fast rekkefølge, og fasen som feilet forteller deg hvilken komponent du skal se på.

Start av tillegget er det første, og en feil der gir en melding om VPN-tjenesten i stedet for om serveren. Deretter kommer en TCP-tilkobling til port 443; en avvisning eller tidsavbrudd her er et tilgjengelighetsproblem, ikke et TLS-problem. Så TLS-håndtrykket og serveridentitetskontrollen, deretter PPP-forhandling og kontobekreftelse, og til slutt adressetildeling og ruter. Overvåk journalctl -f -u NetworkManager mens du aktiverer profilen én gang, og les den første spesifikke linjen i stedet for den siste generiske.

Den rekkefølgen forklarer en vanlig feillesing. En sertifikatklage rapporteres før noen påloggingsinformasjon sendes, så det kan ikke hjelpe å bytte passord; en PPP-avvisning kommer etter et vellykket håndtrykk, så det kan heller ikke hjelpe å bytte sertifikat. Behold den første feilen og fasen dens, og du har en diagnose i stedet for et symptom.

Sertifikattillit og kontopålogging er to separate porter

Håndtrykket validerer at serveren er den du ville nå, ut fra utstederen og navnet du konfigurerte. Først etter det tilbyr PPP-laget brukernavnet og passordet ditt til gatewayens autentiseringsmetode. To uavhengige kontroller, altså, vurdert i fast rekkefølge, med separate innstillinger for hver. Ingenting som skrives i passordfeltet kan påvirke den første.

En profil som stoler på feil utsteder, feiler ved første port med en identitetsfeil. En profil som stoler riktig på den, men lagrer et utdatert passord, feiler ved den andre med en autentiseringsavvisning. Begge ser ut som en VPN som ikke vil koble til, og ingen av dem løses av den andres middel.

Hent forventet utsteder og servernavn fra den som drifter gatewayen i stedet for å gjette på editorens standardverdier, og noter autentiseringsmetoden de krever. Hvis organisasjonen trenger en metode som tillegget ikke kan uttrykke, er det ærlige svaret en godkjent klient som kan, ikke en profil med validering slått av for å få feilen til å forsvinne.

La én eier holde profilen og hemmelighetene

Når profilen finnes, aktiver den via NetworkManager og la den behandleren eie rutene og resolverendringene som følger. Å starte en andre frittstående SSTP-klient mens NetworkManager allerede kjører tilkoblingen, gir deg to sett med ruter, to DNS-konfigurasjoner og en feilsøkingsøkt uten én enkelt sannhetskilde.

Hemmeligheter har også en eier. En tilkobling merket for systemomfattende bruk lagrer påloggingsinformasjon annerledes enn en som er begrenset til brukerøkten din, og en profil som er laget for hånd i en nøkkelfil, er kanskje ikke lesbar for hemmelighetsagenten som forventer å levere passordet interaktivt. Sjekk hvilken kontekst profilen forventer, før du skriver inn et passord som aldri var problemet. Å aktivere samme profil fra en terminal med nmcli er den raskeste testen, fordi en forespørsel som aldri vises, forteller deg at agenten allerede ikke hadde noe å tilby.

Sjekk tunnelen, rutene og resolveren hver for seg

En tilkoblet-indikator hevder bare at lenken kom opp. Sjekk destinasjonen du faktisk trenger, ruten som bærer den, og resolveren som brukes, én om gangen; hver av dem kan være feil mens de to andre er i orden.

For et mislykket forsøk, ta vare på versjonen av hver komponent og den rensede feilteksten. Del dem, ikke hele profilen, fordi profilen kan inneholde den forhåndsdelte hemmeligheten og de lagrede påloggingsdetaljene dine.

Til slutt, koble fra og til igjen, og start deretter på nytt én gang. Hvis profilen bare virker ved første forsøk, ligger problemet i håndteringen av hemmeligheter eller i ruteeierskap, og begge er billigere å rette nå enn midt i en arbeidsdag.