SSTP su Linux fallisce prima del login? Controllate i componenti di runtime

Installi il plugin SSTP, il pulsante di opzione appare nell'editor di rete, inserisci un gateway e un nome utente, e il profilo fallisce con un errore generico prima ancora di chiedere una password. Nulla in questa sequenza è insolito, e nulla in essa dimostra che il software del tunnel sia installato. Una connessione SSTP è assemblata da parti fornite separatamente: un plugin VPN che NetworkManager può avviare, il programma client SSTP che possiede la sessione TLS e PPP, il demone PPP sottostante e un archivio di segreti che la connessione è autorizzata a leggere.

Cosa aggiunge la voce di menu e cosa no

Il plugin fornisce una descrizione del servizio che dice a NetworkManager come avviarlo, e sulla maggior parte delle distribuzioni un piccolo editor che disegna il modulo. Questa è l'intera portata della voce di menu. Il programma client proviene da un pacchetto sorgente diverso, e il README del plugin stesso dice la separazione chiaramente: è un plugin, non un client.

Il client ha poi bisogno di PPP, perché SSTP trasporta una sessione PPP dentro una connessione TLS. Senza pppd il tunnel può completare l'handshake TLS e morire comunque al primo frame di controllo, cosa che sembra un problema di credenziali e non lo è. Su Debian e Ubuntu le parti arrivano come network-manager-sstp, sstp-client e ppp, e installare solo la prima è la ragione più comune per cui un modulo accetta ogni campo mentre la connessione non si completa mai.

La scelta del desktop aggiunge un'altra separazione. Plasma modifica i profili tramite plasma-nm, che necessita di un proprio componente SSTP e legge la stessa descrizione del servizio, quindi un editor senza voce SSTP e una CLI che crea profili senza problemi sono una metà dell'editor mancante, non un runtime rotto.

Leggete la prima fase che fallisce prima di reinstallare qualsiasi cosa

Un tentativo SSTP fallito attraversa fasi in un ordine fisso, e la fase che ha fallito vi dice quale componente guardare.

L'avvio del plugin è la prima, e un errore lì produce un messaggio sul servizio VPN, non sul server. Poi arriva una connessione TCP alla porta 443; un rifiuto o un timeout qui è un problema di raggiungibilità, non di TLS. Poi l'handshake TLS e il controllo dell'identità del server, quindi la negoziazione PPP e l'autenticazione dell'account, e infine l'assegnazione degli indirizzi e le rotte. Osservate journalctl -f -u NetworkManager mentre attivate il profilo una volta, e leggete la prima riga specifica invece dell'ultima generica.

Quest'ordine spiega una lettura errata comune. Una lamentela sul certificato viene segnalata prima che venga inviata qualsiasi credenziale, quindi cambiare la password non può aiutare; un rifiuto di autenticazione PPP arriva dopo un handshake riuscito, quindi sostituire il certificato non aiuta neanche. Tenete il primo errore e la sua fase, e avete una diagnosi invece di un sintomo.

Fiducia nel certificato e accesso all'account sono due porte separate

L'handshake verifica che il server sia quello che volevate raggiungere, usando l'emittente e il nome che avete configurato. Solo dopo il livello PPP offre nome utente e password al metodo di autenticazione del gateway. Due controlli indipendenti, dunque, valutati in un ordine fisso, con impostazioni separate per ciascuno. Nulla di ciò che viene digitato nel campo password può influenzare il primo.

Un profilo che si fida dell'emittente sbagliato fallisce al primo cancello con un errore di identità. Un profilo che si fida correttamente ma memorizza una password obsoleta fallisce al secondo con un rifiuto di autenticazione. Entrambi sembrano una VPN che non si collegherà, e nessuno dei due si risolve con il rimedio dell'altro.

Ottenete l'emittente e il nome server attesi da chi gestisce il gateway invece di indovinare i valori predefiniti dell'editor, e annotate il metodo di autenticazione richiesto. Se l'organizzazione necessita di un metodo che il plugin non può esprimere, la risposta onesta è un client approvato che può, non un profilo con la convalida disattivata per far sparire l'errore.

Lasciate che un solo proprietario tenga profilo e segreti

Una volta che il profilo esiste, attivatelo tramite NetworkManager e lasciate che quel gestore possieda le rotte e le modifiche al resolver risultanti. Avviare un secondo client SSTP autonomo mentre NetworkManager gestisce già la connessione vi dà due insiemi di rotte, due configurazioni DNS e una sessione di debug senza un'unica fonte di verità.

Anche i segreti hanno un proprietario. Una connessione contrassegnata per l'uso a livello di sistema memorizza le credenziali diversamente da una limitata alla vostra sessione utente, e un profilo creato a mano in un file di chiavi potrebbe non essere leggibile dall'agente dei segreti che si aspetta di fornire la password in modo interattivo. Controllate quale contesto si aspetta il profilo prima di ridigitare una password che non è mai stata il problema. Attivare lo stesso profilo da un terminale con nmcli è il test più rapido, perché un prompt che non appare mai vi dice che l'agente non aveva già nulla da offrire.

Verificate tunnel, rotte e resolver separatamente

Un indicatore di connesso afferma solo che il collegamento è salito. Controllate la destinazione che vi serve davvero, la rotta che la trasporta e il resolver in uso, uno alla volta; ciascuno può essere sbagliato mentre gli altri due sono a posto.

Per un tentativo fallito, registrate la versione di ciascun componente e il testo dell'errore ripulito. Condividete quelli, non il profilo completo, perché il profilo può contenere il segreto precondiviso e le vostre credenziali memorizzate.

Infine, disconnettete e riconnettete, poi riavviate una volta. Se il profilo funziona solo al primo tentativo, il problema sta nella gestione dei segreti o nella proprietà delle rotte, ed entrambi sono più economici da correggere ora che a metà di una giornata lavorativa.