Port 443 svarer, SSTP fejler stadig: hvilket trin brød sammen?

At fuldføre et TCP-håndtryk til port 443, mens tunnelen aldrig bygges, beviser én ting, og det er en lille ting. Noget lytter og er villigt til at acceptere en forbindelse på den adresse. Det identificerer ikke tjenesten, det certifikat den vil præsentere, eller hvad der sker efter de første bytes.

Fire trin ligger mellem det håndtryk og en fungerende tunnel, og hvert trin giver en forskellig fejl.

En åben port beskriver kun ét lag

At acceptere en TCP-forbindelse betyder, at en proces ejer soklen, og at stien tillader håndtrykket. Det siger intet om, hvorvidt den proces er en SSTP-server, om den har et certifikat, der er gyldigt for navnet i din profil, eller om den vil godkende din konto. En webserver på samme adresse besvarer håndtrykket perfekt og svarer derefter på din SSTP-anmodning med en HTTP-fejl. Alt over det håndtryk forbliver utestet.

Behandl porttesten som det billigst mulige filter i stedet for som en dom. Dens værdi er, at den fjerner en hel kategori af fejl, ikke at den bekræfter alt oven over.

At forveksle de to er grunden til, at folk geninstallerer klienter efter en test, der aldrig undersøgte klientens faktiske problem.

Adskil de fire trin med beviser

Trinnene er transportens tilgængelighed, TLS-validering, SSTP-udvekslingen over HTTPS og PPP-godkendelse inde i tunnelen. En sti, der består den første og fejler den fjerde, kræver en rettelse af loginoplysninger; en, der fejler den anden, kræver en rettelse af certifikat eller navn. Disse reparationer har intet til fælles, og at vælge den forkerte spilder afbrydelsen.

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/

Den tredje kommando er værd at læse grundigt. Et 200 fra en almindelig webside fortæller dig, at der er en webtjeneste; det fortæller dig ikke, at SSTP-anmodningen vil blive forstået. Et 404 fra samme adresse er lige så intetsigende om VPN’en. Kun klientloggen fortæller dig, hvilket af de fire trin den nåede.

Bemærk, hvilket navn hver kommando brugte. Certifikatet vælges efter det navn, du sender, så en uoverensstemmelse mellem profilen og testen er en uoverensstemmelse, du selv indførte. At skrive det navn ved siden af resultatet forhindrer forvirringen senere.

Læs delvis succes i den rigtige retning

En mellemled kan tillade almindelig browsing og afvise den senere udveksling, og derfor kan en proxy, der virker til websites, stadig fejle til en tunnel. Det samme mønster viser sig, når et certifikat er gyldigt for et browsernavn men ikke for det navn, der er konfigureret i profilen: browseren er tilfreds, og klienten er ikke, og begge har ret om det, de kontrollerede.

Hold servervalidering aktiveret, mens du diagnosticerer dette. At slå den fra omdanner en certifikat-uoverensstemmelse til et vellykket håndtryk og skjuler det eneste bevis, der ville have forklaret fejlen.

Hvis den samme profil virker fra et andet netværk, er forskellen stiafhængig. Det indsnævrer søgningen til mellemled uden at sige hvilket, og det er stadig et nyttigt skridt fremad. Noter det netværk, du brugte, fordi sammenligningen er værdiløs uden det.

Test derefter applikationen, ikke bare sessionen

Når en session findes, skal du kontrollere den tilsigtede rute, navneopløsning og tjenestetilladelse fra den klient, der har brug for dem. En tilsluttet tunnel kan stadig mangle videresendelse i den fjerne ende eller have en returrute, der aldrig har eksisteret, og disse fejl ser præcis ud som et applikationsproblem for den person, der venter.

Hold hver konklusion knyttet til det trin, der producerede den. At kalde en åben port en fungerende VPN er, hvordan en fem minutters certifikatkontrol bliver til en dag med geninstallation af software.