SSTP på Linux fejler før login? Kontrollér køretidsdelene

Du installerer SSTP-pluginet, radioknappen dukker op i netværkseditoren, du udfylder en gateway og et brugernavn, og profilen fejler med en generisk fejl, før den overhovedet spørger om en adgangskode. Intet ved den sekvens er usædvanligt, og intet i den beviser, at tunnelsoftwaren er installeret. En SSTP-forbindelse samles af dele, der leveres separat: et VPN-plugin, som NetworkManager kan starte, SSTP-klientprogrammet, der ejer TLS- og PPP-sessionen, PPP-dæmonen nedenunder og et hemmelighedslager, som forbindelsen har lov til at læse.

Hvad menupunktet tilføjer, og hvad det ikke gør

Pluginet bidrager med en tjenestebeskrivelse, der fortæller NetworkManager, hvordan det skal startes, og på de fleste distributioner en lille editor, der tegner formularen. Det er hele omfanget af menupunktet. Klientprogrammet kommer fra en anden kildekodepakke, og pluginiets egen README siger opdelingen direkte: det er et plugin, ikke en klient.

Klienten har derefter brug for PPP, fordi SSTP bærer en PPP-session inde i en TLS-forbindelse. Uden pppd kan tunnelen fuldføre sit TLS-håndtryk og alligevel dø ved den første kontrolramme, hvilket lyder som et legitimationsproblem og ikke er det. På Debian og Ubuntu leveres delene som network-manager-sstp, sstp-client og ppp, og at installere kun den første er den mest almindelige grund til, at en formular accepterer hvert felt, mens forbindelsen aldrig bliver færdig.

Valget af skrivebord tilføjer endnu en opdeling. Plasma redigerer profiler via plasma-nm, som har brug for sin egen SSTP-komponent og læser den samme tjenestebeskrivelse, så en editor uden SSTP-punkt og en CLI, der sagtens kan oprette profiler, er en manglende halvdel af editoren, ikke en ødelagt køretid.

Læs den første fejlende fase, før du geninstallerer noget

Et mislykket SSTP-forsøg går gennem faser i en fast rækkefølge, og den fase, der fejlede, fortæller dig, hvilken komponent du skal se på.

Start af pluginet er det første, og en fejl der giver en meddelelse om VPN-tjenesten i stedet for om serveren. Derefter kommer en TCP-forbindelse til port 443; et afslag eller en timeout her er et tilgængelighedsproblem, ikke et TLS-problem. Så TLS-håndtrykket og serveridentitetskontrollen, derefter PPP-forhandling og kontobekræftelse, og til sidst tildeling af adresse og ruter. Overvåg journalctl -f -u NetworkManager, mens du aktiverer profilen én gang, og læs den første specifikke linje i stedet for den sidste generiske.

Den rækkefølge forklarer en almindelig fejllæsning. En certifikatklage rapporteres, før nogen legitimationsoplysninger sendes, så det kan ikke hjælpe at skifte adgangskode; en PPP-afvisning kommer efter et vellykket håndtryk, så det kan heller ikke hjælpe at udskifte certifikatet. Behold den første fejl og dens fase, og du har en diagnose i stedet for et symptom.

Certifikattillid og kontologin er separate porte

Håndtrykket validerer, at serveren er den, du ville nå, ud fra den udsteder og det navn, du har konfigureret. Først derefter tilbyder PPP-laget dit brugernavn og din adgangskode til gatewayens godkendelsesmetode. To uafhængige kontroller, altså, vurderet i en fast rækkefølge, med separate indstillinger for hver. Intet, der tastes i adgangskodefeltet, kan påvirke den første.

En profil, der stoler på den forkerte udsteder, fejler ved den første port med en identitetsfejl. En profil, der stoler korrekt på den, men gemmer en forældet adgangskode, fejler ved den anden med en godkendelsesafvisning. Begge ser ud som en VPN, der ikke vil forbinde, og ingen af dem løses af den andens middel.

Hent den forventede udsteder og det forventede servernavn fra den, der driver gatewayen, i stedet for at gætte på editorens standardværdier, og notér den godkendelsesmetode, de kræver. Hvis organisationen har brug for en metode, som pluginet ikke kan udtrykke, er det ærlige svar en godkendt klient, der kan, ikke en profil med validering slået fra for at få fejlen til at forsvinde.

Lad én ejer holde profilen og hemmelighederne

Når profilen findes, skal du aktivere den via NetworkManager og lade den manager eje de resulterende ruter og resolverændringer. Starter du en anden selvstændig SSTP-klient, mens NetworkManager allerede kører forbindelsen, får du to sæt ruter, to DNS-konfigurationer og en fejlretningssession uden én enkelt kilde til sandhed.

Hemmeligheder har også en ejer. En forbindelse markeret til systemdækkende brug gemmer legitimationsoplysninger anderledes end en, der er begrænset til din brugersession, og en profil, der er oprettet manuelt i en nøglefil, er måske ikke læsbar for den hemmelighedsagent, der forventer at levere adgangskoden interaktivt. Kontrollér, hvilken kontekst profilen forventer, før du gentaster en adgangskode, der aldrig var problemet. Aktivering af den samme profil fra en terminal med nmcli er den hurtigste test, fordi en prompt, der aldrig vises, fortæller dig, at agenten allerede ikke havde noget at tilbyde.

Kontrollér tunnelen, ruterne og resolveren hver for sig

En forbundet-indikator hævder kun, at linket kom op. Kontrollér destinationen, du faktisk har brug for, ruten, der bærer den, og den resolver, der bruges, én ad gangen; hver af dem kan være forkert, mens de to andre er fine.

For et mislykket forsøg skal du registrere versionen af hver komponent og den rensede fejltekst. Del dem, ikke hele profilen, fordi profilen kan indeholde den foruddelte hemmelighed og dine gemte legitimationsoplysninger.

Til sidst skal du afbryde og genoprette forbindelsen og derefter genstarte én gang. Hvis profilen kun virker ved første forsøg, ligger problemet i håndteringen af hemmeligheder eller i ruteejerskab, og begge er billigere at rette nu end midt i en arbejdsdag.