SSTP på Linux feilar før innlogging? Sjekk køyretidsdelane

Du installerer SSTP-tillegget, radioknappen dukkar opp i nettverkseditoren, du fyller inn ein gateway og eit brukarnamn, og profilen feilar med ein generisk feil før han i det heile spør om eit passord. Ingenting ved den sekvensen er uvanleg, og ingenting i han beviser at tunnelprogramvaren er installert. Ei SSTP-tilkopling blir sett saman av delar som blir leverte separat: eit VPN-tillegg som NetworkManager kan starte, SSTP-klientprogrammet som eig TLS- og PPP-økta, PPP-demonen under det, og eit løyndomslager som tilkoplinga har lov til å lese.

Kva menypunktet tilfører, og kva det ikkje gjer

Tillegget bidreg med ei tenesteskildring som fortel NetworkManager korleis det skal startast, og på dei fleste distribusjonar ein liten editor som teiknar skjemaet. Det er heile omfanget av menypunktet. Klientprogrammet kjem frå ein annan kjeldekodepakke, og tilleggets eigen README seier delinga rett ut: det er eit tillegg, ikkje ein klient.

Klienten treng deretter PPP, fordi SSTP ber ei PPP-økt inne i ei TLS-tilkopling. Utan pppd kan tunnelen fullføre TLS-handtrykket og likevel døy ved den første kontrollramma, noko som ser ut som eit problem med påloggingsinformasjon og ikkje er det. På Debian og Ubuntu kjem delane som network-manager-sstp, sstp-client og ppp, og å installere berre den første er den vanlegaste grunnen til at eit skjema godtek kvart felt medan tilkoplinga aldri blir fullført.

Valet av skrivebord legg til ei deling til. Plasma redigerer profilar via plasma-nm, som treng sin eigen SSTP-komponent og les den same tenesteskildringa, så ein editor utan SSTP-punkt og ein CLI som lagar profilar fint, er ein manglande halvdel av editoren, ikkje ein øydelagd køyretid.

Les den første feilande fasen før du installerer noko på nytt

Eit mislukka SSTP-forsøk går gjennom fasar i fast rekkjefølgje, og fasen som feila fortel deg kva komponent du skal sjå på.

Start av tillegget er det første, og ein feil der gir ei melding om VPN-tenesta i staden for om serveren. Deretter kjem ei TCP-tilkopling til port 443; ei avvising eller tidsavbrot her er eit tilgjengeproblem, ikkje eit TLS-problem. Så TLS-handtrykket og serveridentitetskontrollen, deretter PPP-forhandling og kontobekrefting, og til slutt adressetildeling og ruter. Overvak journalctl -f -u NetworkManager medan du aktiverer profilen éin gong, og les den første spesifikke linja i staden for den siste generiske.

Den rekkjefølgja forklarer ei vanleg feillesing. Ei sertifikatklage blir rapportert før nokon påloggingsinformasjon blir send, så det kan ikkje hjelpe å byte passord; ei PPP-avvising kjem etter eit vellukka handtrykk, så det kan heller ikkje hjelpe å byte sertifikat. Hald på den første feilen og fasen hans, og du har ein diagnose i staden for eit symptom.

Sertifikattillit og kontopålogging er to separate portar

Handtrykket validerer at serveren er den du ville nå, ut frå utgivaren og namnet du konfigurerte. Først etter det tilbyr PPP-laget brukarnamnet og passordet ditt til autentiseringsmetoden til gatewayen. To uavhengige kontrollar, altså, vurderte i fast rekkjefølgje, med separate innstillingar for kvar. Ingenting som blir skrive i passordfeltet kan påverke den første.

Ein profil som stolar på feil utgivar, feilar ved første port med ein identitetsfeil. Ein profil som stolar rett på han, men lagrar eit utdatert passord, feilar ved den andre med ei autentiseringsavvising. Begge ser ut som ein VPN som ikkje vil kople til, og ingen av dei blir løyste av middelet til den andre.

Hent forventa utgivar og servernamn frå den som driftar gatewayen i staden for å gjette på standardverdiane til editoren, og noter autentiseringsmetoden dei krev. Viss organisasjonen treng ein metode som tillegget ikkje kan uttrykkje, er det ærlege svaret ein godkjend klient som kan, ikkje ein profil med validering slått av for å få feilen til å forsvinne.

Lat éin eigar halde profilen og løyndommane

Når profilen finst, aktiver han via NetworkManager og lat den behandlaren eige rutene og resolverendringane som følgjer. Å starte ein andre frittståande SSTP-klient medan NetworkManager allereie køyrer tilkoplinga, gir deg to sett med ruter, to DNS-konfigurasjonar og ei feilsøkingsøkt utan éin einaste sanningkjelde.

Løyndommar har òg ein eigar. Ei tilkopling merkt for systemomfattande bruk lagrar påloggingsinformasjon annleis enn ei som er avgrensa til brukarøkta di, og ein profil som er laga for hand i ei nøkkelfil, er kanskje ikkje lesbar for løyndomsagenten som ventar å levere passordet interaktivt. Sjekk kva kontekst profilen ventar, før du skriv inn eit passord som aldri var problemet. Å aktivere same profil frå ein terminal med nmcli er den raskaste testen, fordi ei oppmoding som aldri blir vist, fortel deg at agenten allereie ikkje hadde noko å tilby.

Sjekk tunnelen, rutene og resolveren kvar for seg

Ein tilkopla-indikator hevdar berre at lenka kom opp. Sjekk destinasjonen du faktisk treng, ruta som ber han, og resolveren som blir brukt, éin om gongen; kvar av dei kan vere feil medan dei to andre er i orden.

For eit mislukka forsøk, ta vare på versjonen av kvar komponent og den reinska feilteksten. Del dei, ikkje heile profilen, fordi profilen kan innehalde den førehandsdelte løyndommen og dei lagra påloggingsdetaljane dine.

Til slutt, kople frå og til igjen, og start deretter på nytt éin gong. Viss profilen berre verkar ved første forsøk, ligg problemet i handteringa av løyndommar eller i ruteeigarskap, og begge er billegare å rette no enn midt i ein arbeidsdag.