SSTP op Linux mislukt vóór het inloggen? Controleer de runtime-onderdelen

Je installeert de SSTP-plug-in, de radioknop verschijnt in de netwerk-editor, je vult een gateway en een gebruikersnaam in, en het profiel mislukt met een algemene fout voordat het ooit om een wachtwoord vraagt. Niets aan die volgorde is ongewoon, en niets erin bewijst dat de tunnelssoftware is geïnstalleerd. Een SSTP-verbinding wordt samengesteld uit onderdelen die apart worden geleverd: een VPN-plug-in die NetworkManager kan starten, het SSTP-clientprogramma dat de TLS- en PPP-sessie bezit, de PPP-daemon eronder, en een geheimenopslag die de verbinding mag lezen.

Wat het menu-item toevoegt, en wat niet

De plug-in levert een servicedefinitie die NetworkManager vertelt hoe hij hem moet starten, en op de meeste distributies een kleine editor die het formulier tekent. Dat is de volledige reikwijdte van het menu-item. Het clientprogramma komt uit een ander bronpakket, en de README van de plug-in zelf zegt de splitsing ronduit: het is een plug-in, geen client.

De client heeft daarna PPP nodig, omdat SSTP een PPP-sessie in een TLS-verbinding vervoert. Zonder pppd kan de tunnel zijn TLS-handshake voltooien en toch sterven bij het eerste controleframe, wat op een inloggegevensprobleem lijkt en dat niet is. Op Debian en Ubuntu komen de onderdelen als network-manager-sstp, sstp-client en ppp, en alleen de eerste installeren is de meest voorkomende reden dat een formulier elk veld accepteert terwijl de verbinding nooit tot stand komt.

De keuze van desktop voegt nog een splitsing toe. Plasma bewerkt profielen via plasma-nm, dat een eigen SSTP-component nodig heeft en dezelfde servicedefinitie leest, dus een editor zonder SSTP-item en een CLI die profielen prima aanmaakt, is een ontbrekende helft van de editor, niet een kapotte runtime.

Lees de eerste mislukkende fase voordat je iets opnieuw installeert

Een mislukte SSTP-poging doorloopt fasen in een vaste volgorde, en de fase die mislukte vertelt je naar welke component je moet kijken.

Het starten van de plug-in is de eerste, en een fout daar levert een melding over de VPN-dienst in plaats van over de server. Daarna komt een TCP-verbinding naar poort 443; een weigering of time-out hier is een bereikbaarheidsprobleem, geen TLS-probleem. Dan de TLS-handshake en de serveridentiteitscontrole, daarna PPP-onderhandeling en accountauthenticatie, en ten slotte adresuitgifte en routes. Houd journalctl -f -u NetworkManager in de gaten terwijl je het profiel één keer activeert, en lees de eerste specifieke regel in plaats van de laatste algemene.

Die volgorde verklaart een veelgemaakte verkeerde lezing. Een certificaatklacht wordt gemeld voordat er inloggegevens worden verzonden, dus het wachtwoord wijzigen kan niet helpen; een PPP-authenticatieweigering komt na een geslaagde handshake, dus het certificaat vervangen helpt ook niet. Houd de eerste fout en zijn fase vast, en je hebt een diagnose in plaats van een symptoom.

Certificaattrouw en accountlogin zijn twee aparte poorten

De handshake controleert of de server degene is die je wilde bereiken, met de uitgever en naam die je hebt geconfigureerd. Pas daarna biedt de PPP-laag je gebruikersnaam en wachtwoord aan de authenticatiemethode van de gateway. Dus twee onafhankelijke controles, in een vaste volgorde beoordeeld, met aparte instellingen voor elk. Niets wat in het wachtwoordveld wordt getypt kan de eerste beïnvloeden.

Een profiel dat de verkeerde uitgever vertrouwt, mislukt bij de eerste poort met een identiteitsfout. Een profiel dat hem correct vertrouwt maar een verouderd wachtwoord opslaat, mislukt bij de tweede met een authenticatieweigering. Beide lijken op een VPN die niet zal verbinden, en geen van beide wordt verholpen door het middel van de ander.

Vraag de verwachte uitgever en servernaam aan wie de gateway beheert in plaats van de standaardwaarden van de editor te raden, en noteer de authenticatiemethode die zij eisen. Als de organisatie een methode nodig heeft die de plug-in niet kan uitdrukken, is het eerlijke antwoord een goedgekeurde client die dat wel kan, niet een profiel met validatie uitgeschakeld om de fout te laten verdwijnen.

Laat één eigenaar het profiel en de geheimen beheren

Zodra het profiel bestaat, activeer je het via NetworkManager en laat je die beheerder eigenaar zijn van de resulterende routes en resolverwijzigingen. Een tweede zelfstandige SSTP-client starten terwijl NetworkManager de verbinding al beheert, geeft je twee routesets, twee DNS-configuraties en een debug-sessie zonder één bron van waarheid.

Geheimen hebben ook een eigenaar. Een verbinding die is gemarkeerd voor systeembreed gebruik slaat inloggegevens anders op dan een die beperkt is tot je gebruikerssessie, en een profiel dat met de hand in een sleutelbestand is gemaakt, is mogelijk niet leesbaar voor de geheimenagent die verwacht het wachtwoord interactief te leveren. Controleer welke context het profiel verwacht voordat je een wachtwoord opnieuw typt dat nooit het probleem was. Hetzelfde profiel activeren vanuit een terminal met nmcli is de snelste test, want een prompt die nooit verschijnt, vertelt je dat de agent al niets te bieden had.

Controleer de tunnel, de routes en de resolver apart

Een verbonden-indicator beweert alleen dat de link omhoog is gekomen. Controleer de bestemming die je echt nodig hebt, de route die hem draagt en de resolver die in gebruik is, één voor één; elk kan fout zijn terwijl de andere twee in orde zijn.

Leg voor een mislukte poging de versie van elke component en de opgeschoonde fouttekst vast. Deel die, niet het volledige profiel, want het profiel kan het vooraf gedeelde geheim en je opgeslagen inloggegevens bevatten.

Ten slotte verbreek je de verbinding en maak je opnieuw verbinding, en herstart je één keer. Als het profiel alleen bij de eerste poging werkt, zit het probleem in de omgang met geheimen of in het eigenaarschap van routes, en beide zijn nu goedkoper te verhelpen dan midden in een werkdag.