SSTP på Linux misslyckas före inloggning? Kontrollera körtidsdelarna

Du installerar SSTP-insticksmodulen, radioknappen dyker upp i nätverksredigeraren, du fyller i en gateway och ett användarnamn, och profilen misslyckas med ett allmänt fel innan den ens frågar efter ett lösenord. Inget i den sekvensen är ovanligt, och inget i den bevisar att tunnelmjukvaran är installerad. En SSTP-anslutning sätts ihop av delar som levereras separat: en VPN-insticksmodul som NetworkManager kan starta, SSTP-klientprogrammet som äger TLS- och PPP-sessionen, PPP-demonen under det, och ett hemlighetslager som anslutningen får läsa.

Vad menyvalet tillför, och vad det inte gör

Insticksmodulen bidrar med en tjänstebeskrivning som talar om för NetworkManager hur den ska startas, och på de flesta distributioner en liten redigerare som ritar formuläret. Det är hela omfattningen av menyvalet. Klientprogrammet kommer från ett annat källkodspaket, och insticksmodulens egen README säger delningen rakt ut: det är en insticksmodul, inte en klient.

Klienten behöver sedan PPP, eftersom SSTP bär en PPP-session inuti en TLS-anslutning. Utan pppd kan tunneln slutföra TLS-handskakningen och ändå dö vid den första kontrollramen, vilket ser ut som ett problem med inloggningsuppgifter och inte är det. På Debian och Ubuntu kommer delarna som network-manager-sstp, sstp-client och ppp, och att installera bara den första är den vanligaste orsaken till att ett formulär accepterar varje fält medan anslutningen aldrig slutförs.

Valet av skrivbord lägger till ytterligare en delning. Plasma redigerar profiler via plasma-nm, som behöver sin egen SSTP-komponent och läser samma tjänstebeskrivning, så en redigerare utan SSTP-post och en CLI som skapar profiler bra är en saknad halva av redigeraren, inte en trasig körtid.

Läs den första fasen som misslyckas innan du installerar om något

Ett misslyckat SSTP-försök går igenom faser i fast ordning, och fasen som misslyckades talar om vilken komponent du ska titta på.

Start av insticksmodulen är den första, och ett fel där ger ett meddelande om VPN-tjänsten i stället för om servern. Sedan kommer en TCP-anslutning till port 443; ett avslag eller en timeout här är ett nåbarhetsproblem, inte ett TLS-problem. Sedan TLS-handskakningen och serveridentitetskontrollen, därefter PPP-förhandling och kontobekräftelse, och till sist adresstilldelning och rutter. Övervaka journalctl -f -u NetworkManager medan du aktiverar profilen en gång, och läs den första specifika raden i stället för den sista allmänna.

Den ordningen förklarar en vanlig felläsning. Ett certifikatklagomål rapporteras innan några inloggningsuppgifter skickas, så att byta lösenord kan inte hjälpa; en PPP-avvisning kommer efter en lyckad handskakning, så att byta certifikat hjälper inte heller. Behåll det första felet och dess fas, och du har en diagnos i stället för ett symptom.

Certifikatförtroende och kontoinloggning är två separata portar

Handskakningen validerar att servern är den du ville nå, utifrån utfärdaren och namnet du konfigurerade. Först efter det erbjuder PPP-lagret ditt användarnamn och lösenord till gatewayens autentiseringsmetod. Två oberoende kontroller alltså, bedömda i fast ordning, med separata inställningar för varje. Inget som skrivs i lösenordsfältet kan påverka den första.

En profil som litar på fel utfärdare misslyckas vid första porten med ett identitetsfel. En profil som litar korrekt på den men lagrar ett inaktuellt lösenord misslyckas vid den andra med en autentiseringsavvisning. Båda ser ut som en VPN som inte kommer att ansluta, och ingen av dem åtgärdas av den andras botemedel.

Hämta förväntad utfärdare och servernamn från den som driftar gatewayen i stället för att gissa redigerarens standardvärden, och notera den autentiseringsmetod de kräver. Om organisationen behöver en metod som insticksmodulen inte kan uttrycka, är det ärliga svaret en godkänd klient som kan, inte en profil med validering avstängd för att få felet att försvinna.

Låt en ägare hålla profilen och hemligheterna

När profilen finns, aktivera den via NetworkManager och låt den hanteraren äga rutterna och resolverändringarna som följer. Att starta en andra fristående SSTP-klient medan NetworkManager redan kör anslutningen ger dig två uppsättningar rutter, två DNS-konfigurationer och en felsökningssession utan en enda sanningskälla.

Hemligheter har också en ägare. En anslutning markerad för systemomfattande användning lagrar inloggningsuppgifter annorlunda än en som är begränsad till din användarsession, och en profil som skapats för hand i en nyckelfil är kanske inte läsbar för hemlighetsagenten som förväntar sig att leverera lösenordet interaktivt. Kontrollera vilken kontext profilen förväntar sig innan du skriver in ett lösenord som aldrig var problemet. Att aktivera samma profil från en terminal med nmcli är det snabbaste testet, eftersom en uppmaning som aldrig dyker upp talar om att agenten redan inte hade något att erbjuda.

Kontrollera tunneln, rutterna och resolvern var för sig

En ansluten-indikator hävdar bara att länken kom upp. Kontrollera målet du faktiskt behöver, rutten som bär det och resolvern som används, en i taget; var och en kan vara fel medan de andra två är i ordning.

För ett misslyckat försök, registrera versionen av varje komponent och den rensade feltexten. Dela dem, inte hela profilen, eftersom profilen kan innehålla den fördelade hemligheten och dina lagrade inloggningsuppgifter.

Slutligen, koppla från och anslut igen, och starta sedan om en gång. Om profilen bara fungerar vid första försöket ligger problemet i hanteringen av hemligheter eller i ruteägandet, och båda är billigare att åtgärda nu än mitt i en arbetsdag.