SSTP a Linux falla abans de l'inici de sessió? Reviseu les peces d'execució

Instal·leu el connector SSTP, apareix el botó ràdio a l'editor de xarxa, introduïu una passarel·la i un nom d'usuari, i el perfil falla amb un error genèric abans que demani cap contrasenya. No hi ha res d'estrany en aquesta seqüència i res no demostra que el programari del túnel estigui instal·lat. Una connexió SSTP es munta amb peces que es distribueixen per separat: un connector de VPN que NetworkManager pot executar, el programa client SSTP que posseeix la sessió TLS i PPP, el dimoni PPP a sota, i un magatzem de secrets que la connexió té permès de llegir.

Què afegeix l'entrada de menú i què no

El connector aporta una descripció del servei que diu a NetworkManager com iniciar-lo, i a la majoria de distribucions un petit editor que dibuixa el formulari. Aquest és tot l'abast de l'entrada de menú. El programa client ve d'un paquet font diferent, i el README del mateix connector diu la separació directament: és un connector, no un client.

El client necessita després PPP, perquè SSTP transporta una sessió PPP dins d'una connexió TLS. Sense pppd el túnel pot completar l'apretada de mans TLS i morir igualment a la primera trama de control, cosa que sembla un problema de credencials i no ho és. A Debian i Ubuntu les peces arriben com network-manager-sstp, sstp-client i ppp, i instal·lar només la primera és la causa més habitual que un formulari accepti tots els camps mentre la connexió no s'acaba mai.

L'elecció d'escriptori afegeix una altra separació. Plasma edita perfils mitjançant plasma-nm, que necessita el seu propi component SSTP i llegeix la mateixa descripció del servei, així que un editor sense entrada SSTP i una CLI que crea perfils bé és una meitat d'editor que falta, no un entorn d'execució trencat.

Llegiu la primera etapa que falla abans de reinstal·lar res

Un intent SSTP fallit passa per etapes en un ordre fix, i l'etapa que ha fallat us diu a quin component heu de mirar.

Llançar el connector és la primera, i una fallada allà produeix un missatge sobre el servei VPN, no sobre el servidor. Després ve una connexió TCP al port 443; una denegació o un temps d'espera aquí és un problema d'abast, no de TLS. Després l'apretada de mans TLS i la comprovació d'identitat del servidor, després la negociació PPP i l'autenticació del compte, i finalment l'assignació d'adreces i les rutes. Observeu journalctl -f -u NetworkManager mentre activeu el perfil una vegada, i llegiu la primera línia específica en lloc de l'última genèrica.

Aquest ordre explica una lectura incorrecta habitual. Una queixa de certificat es reporta abans que s'enviï cap credencial, així que canviar la contrasenya no pot ajudar; un rebuig d'autenticació PPP arriba després d'una apretada de mans correcta, així que substituir el certificat tampoc no ajuda. Quedeu-vos amb el primer error i la seva etapa, i tindreu un diagnòstic en lloc d'un símptoma.

La confiança en el certificat i l'inici de sessió són portes separades

L'apretada de mans valida que el servidor és el que volíeu assolir, amb l'emissor i el nom que heu configurat. Només després la capa PPP ofereix el vostre nom d'usuari i contrasenya al mètode d'autenticació de la passarel·la. Dues comprovacions independents, doncs, avaluades en un ordre fix, amb paràmetres separats per a cadascuna. Res del que s'escriu al camp de contrasenya no pot influir en la primera.

Un perfil que confia en l'emissor equivocat falla a la primera porta amb un error d'identitat. Un perfil que hi confia correctament però guarda una contrasenya antiga falla a la segona amb un rebuig d'autenticació. Tots dos semblen una VPN que no es connectarà, i cap dels dos no es resol amb el remei de l'altre.

Obteniu l'emissor i el nom del servidor esperats de qui gestiona la passarel·la en lloc d'endevinar els valors per defecte de l'editor, i anoteu el mètode d'autenticació que requereixen. Si l'organització necessita un mètode que el connector no pot expressar, la resposta honesta és un client aprovat que sí que pugui, no un perfil amb la validació desactivada per fer desaparèixer l'error.

Deixeu que un sol propietari tingui el perfil i els secrets

Un cop el perfil existeix, activeu-lo mitjançant NetworkManager i deixeu que aquest gestor posseeixi les rutes i els canvis de resolutor resultants. Iniciar un segon client SSTP autònom mentre NetworkManager ja porta la connexió us dona dos conjunts de rutes, dues configuracions de DNS i una sessió de depuració sense una única font de veritat.

Els secrets també tenen propietari. Una connexió marcada per a ús de tot el sistema desa les credencials de manera diferent d'una de limitada a la vostra sessió d'usuari, i un perfil creat a mà en un fitxer de claus pot no ser llegible per l'agent de secrets que espera subministrar la contrasenya interactivament. Comproveu quin context espera el perfil abans de tornar a escriure una contrasenya que mai no era el problema. Activar el mateix perfil des d'un terminal amb nmcli és la prova més ràpida, perquè un avís que no apareix mai us diu que l'agent ja no tenia res a oferir.

Verifiqueu el túnel, les rutes i el resolutor per separat

Un indicador de connectat només afirma que l'enllaç ha pujat. Comproveu la destinació que realment necessiteu, la ruta que la transporta i el resolutor en ús, un alhora; cadascun pot estar malament mentre els altres dos estan bé.

Per a un intent fallit, captureu la versió de cada component i el text de l'error sanejat. Compartiu això, no el perfil complet, perquè el perfil pot contenir el secret precompartit i les vostres credencials desades.

Finalment, desconnecteu i torneu a connectar, i reinicieu un cop. Si el perfil només funciona al primer intent, el problema és en la gestió dels secrets o en la propietat de les rutes, i tots dos són més barats d'arreglar ara que a mig dia de feina.