Poort 443 antwoordt, SSTP faalt nog steeds: welke fase brak?

Een TCP-handshake naar poort 443 voltooien terwijl de tunnel nooit wordt opgebouwd bewijst één ding, en het is een klein ding. Iets luistert en is bereid een verbinding op dat adres te accepteren. Het identificeert niet de dienst, het certificaat dat wordt gepresenteerd, of wat er na de eerste bytes gebeurt.

Tussen die handshake en een werkende tunnel liggen vier fasen, en elk levert een andere fout op.

Een open poort beschrijft slechts één laag

Een TCP-verbinding accepteren betekent dat een proces de socket bezit en dat het pad de handshake toestaat. Het zegt niets over of dat proces een SSTP-server is, of het een certificaat heeft dat geldig is voor de naam in je profiel, of het je account zal autoriseren. Een webserver op hetzelfde adres beantwoordt de handshake perfect en antwoordt daarna op je SSTP-verzoek met een HTTP-fout. Alles boven die handshake blijft ongetest.

Behandel de poorttest als het goedkoopst mogelijke filter en niet als een vonnis. De waarde ervan is dat het een hele categorie storingen wegneemt, niet dat het alles erboven bevestigt.

De twee verwarren is de reden dat mensen clients opnieuw installeren na een test die nooit het werkelijke probleem van de client had onderzocht.

Scheid de vier fasen met bewijs

De fasen zijn bereikbaarheid van transport, TLS-validatie, de SSTP-uitwisseling over HTTPS en PPP-authenticatie in de tunnel. Een pad dat de eerste haalt en de vierde faalt, heeft een correctie van inloggegevens nodig; een dat de tweede faalt, heeft een correctie van certificaat of naam nodig. Die reparaties hebben niets gemeen, en de verkeerde kiezen verspilt de storing.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

Het derde commando is het waard aandachtig te lezen. Een 200 van een gewone webpagina zegt je dat er een webservice is; het zegt niet dat het SSTP-verzoek begrepen zal worden. Een 404 van hetzelfde adres is even oninformatief over de VPN. Alleen de clientlog zegt je welke van de vier fasen is bereikt.

Let op welke naam elk commando gebruikte. Het certificaat wordt gekozen op basis van de naam die je stuurt, dus een mismatch tussen het profiel en de test is een mismatch die je zelf hebt geïntroduceerd. Die naam naast het resultaat schrijven voorkomt later de verwarring.

Lees gedeeltelijk succes in de juiste richting

Een tussenpartij kan gewoon browsen toestaan en de latere uitwisseling weigeren, waardoor een proxy die voor websites werkt nog steeds kan falen voor een tunnel. Hetzelfde patroon verschijnt wanneer een certificaat geldig is voor een browsernaam maar niet voor de naam die in het profiel is geconfigureerd: de browser is tevreden en de client niet, en beide hebben gelijk over wat ze hebben gecontroleerd.

Houd servervalidatie ingeschakeld terwijl je dit diagnosticeert. Het uitschakelen verandert een certificaatmismatch in een geslaagde handshake en verbergt het enige bewijs dat de storing zou hebben verklaard.

Als hetzelfde profiel vanaf een ander netwerk werkt, is het verschil padgebonden. Dat beperkt de zoektocht tot tussenpartijen zonder te zeggen welke, en het is nog steeds een nuttige stap vooruit. Noteer het netwerk dat je gebruikte, want de vergelijking is waardeloos zonder.

Test daarna de toepassing, niet alleen de sessie

Zodra er een sessie bestaat, verifieer de beoogde route, naamresolutie en diensttoestemming vanaf de client die ze nodig heeft. Een verbonden tunnel kan nog steeds ontbrekende doorsturing aan de andere kant hebben of een retourroute die nooit bestond, en die fouten lijken voor de wachtende persoon precies op een toepassingsprobleem.

Houd elke conclusie gekoppeld aan de fase die haar heeft opgeleverd. Een open poort een werkende VPN noemen is hoe een certificaatcontrole van vijf minuten een dag software herinstalleren wordt.