SSTP pe Linux eșuează înainte de autentificare? Verificați componentele de execuție

Instalați pluginul SSTP, butonul radio apare în editorul de rețea, completați un gateway și un nume de utilizator, iar profilul eșuează cu o eroare generică înainte de a cere vreo parolă. Nimic din această secvență nu este neobișnuit și nimic din ea nu dovedește că software-ul tunelului este instalat. O conexiune SSTP este asamblată din piese livrate separat: un plugin VPN pe care NetworkManager îl poate lansa, programul client SSTP care deține sesiunea TLS și PPP, demonul PPP de dedesubt și un depozit de secrete pe care conexiunea are voie să îl citească.

Ce adaugă intrarea de meniu și ce nu adaugă

Pluginul contribuie cu o descriere de serviciu care îi spune NetworkManager cum să îl pornească, iar pe majoritatea distribuțiilor cu un mic editor care desenează formularul. Acesta este întregul domeniu al intrării de meniu. Programul client vine dintr-un pachet sursă diferit, iar README-ul pluginului spune separarea direct: este un plugin, nu un client.

Clientul are apoi nevoie de PPP, deoarece SSTP transportă o sesiune PPP într-o conexiune TLS. Fără pppd tunelul poate finaliza strângerea de mână TLS și totuși poate muri la primul cadru de control, ceea ce arată ca o problemă de acreditări și nu este. Pe Debian și Ubuntu piesele vin ca network-manager-sstp, sstp-client și ppp, iar instalarea doar a primei este cel mai frecvent motiv pentru care un formular acceptă fiecare câmp, dar conexiunea nu se termină niciodată.

Alegerea desktopului adaugă încă o separare. Plasma editează profiluri prin plasma-nm, care are nevoie de propria componentă SSTP și citește aceeași descriere de serviciu, așa că un editor fără intrare SSTP și un CLI care creează profiluri bine reprezintă o jumătate de editor lipsă, nu un mediu de execuție stricat.

Citiți prima etapă care eșuează înainte de a reinstala ceva

O încercare SSTP eșuată trece prin etape într-o ordine fixă, iar etapa care a eșuat vă spune la ce componentă să vă uitați.

Lansarea pluginului este prima, iar un eșec acolo produce un mesaj despre serviciul VPN, nu despre server. Urmează o conexiune TCP la portul 443; un refuz sau un timeout aici este o problemă de accesibilitate, nu de TLS. Apoi strângerea de mână TLS și verificarea identității serverului, apoi negocierea PPP și autentificarea contului, iar la final alocarea adreselor și rutele. Urmăriți journalctl -f -u NetworkManager în timp ce activați profilul o dată, și citiți prima linie specifică în loc de ultima generică.

Acea ordine explică o citire greșită obișnuită. O reclamație despre certificat este raportată înainte de a fi trimise acreditări, deci schimbarea parolei nu poate ajuta; o respingere a autentificării PPP vine după o strângere de mână reușită, deci nici înlocuirea certificatului nu ajută. Păstrați prima eroare și etapa ei, și aveți un diagnostic, nu un simptom.

Încrederea în certificat și autentificarea în cont sunt porți separate

Strângerea de mână validează că serverul este cel pe care voiați să îl atingeți, folosind emitentul și numele pe care le-ați configurat. Abia după aceea stratul PPP oferă numele de utilizator și parola metodei de autentificare a gateway-ului. Două verificări independente, deci, evaluate într-o ordine fixă, cu setări separate pentru fiecare. Nimic din ce este tastat în câmpul parolei nu poate influența prima.

Un profil care are încredere în emitentul greșit eșuează la prima poartă cu o eroare de identitate. Un profil care are încredere corectă în el, dar stochează o parolă veche, eșuează la a doua cu o respingere a autentificării. Ambele arată ca un VPN care nu se va conecta, și niciunul nu este reparat de remediul celuilalt.

Obțineți emitentul și numele de server așteptate de la cine administrează gateway-ul în loc să ghiciți valorile implicite ale editorului, și notați metoda de autentificare cerută. Dacă organizația are nevoie de o metodă pe care pluginul nu o poate exprima, răspunsul onest este un client aprobat care poate, nu un profil cu validarea oprită pentru ca eroarea să dispară.

Lăsați un singur proprietar cu profilul și secretele

Odată ce profilul există, activați-l prin NetworkManager și lăsați acel manager să dețină rutele și modificările de resolver rezultate. Pornirea unui al doilea client SSTP autonom în timp ce NetworkManager conduce deja conexiunea vă oferă două seturi de rute, două configurații DNS și o sesiune de depanare fără o singură sursă de adevăr.

Secretele au și ele un proprietar. O conexiune marcată pentru utilizare la nivel de sistem stochează acreditările diferit de una limitată la sesiunea utilizatorului, iar un profil creat manual într-un fișier de chei poate să nu fie lizibil pentru agentul de secrete care se așteaptă să furnizeze parola interactiv. Verificați ce context așteaptă profilul înainte de a retasta o parolă care nu a fost niciodată problema. Activarea aceluiași profil dintr-un terminal cu nmcli este cel mai rapid test, pentru că un prompt care nu apare niciodată vă spune că agentul nu mai avea nimic de oferit.

Verificați tunelul, rutele și resolverul separat

Un indicator de conectat afirmă doar că legătura a urcat. Verificați destinația de care aveți într-adevăr nevoie, ruta care o transportă și resolverul folosit, unul câte unul; fiecare poate fi greșit în timp ce celelalte două sunt în regulă.

Pentru o încercare eșuată, notați versiunea fiecărei componente și textul erorii curățat. Împărtășiți-le, nu profilul complet, pentru că profilul poate conține secretul prepartajat și acreditările dumneavoastră stocate.

În final, deconectați-vă și reconectați-vă, apoi reporniți o dată. Dacă profilul funcționează doar la prima încercare, problema stă în tratarea secretelor sau în proprietatea rutelor, iar ambele sunt mai ieftin de reparat acum decât la mijlocul unei zile lucrătoare.