Port 443 svarar, SSTP misslyckas fortfarande: vilket steg brast?

Att slutföra en TCP-handskakning mot port 443 medan tunneln aldrig byggs bevisar en sak, och det är en liten sak. Något lyssnar och är redo att acceptera en anslutning på den adressen. Det identifierar inte tjänsten, certifikatet som kommer att presenteras eller vad som händer efter de första byten.

Fyra steg ligger mellan den handskakningen och en fungerande tunnel, och varje steg ger ett annat fel.

En öppen port beskriver bara ett lager

Att acceptera en TCP-anslutning betyder att en process äger socketen och att vägen tillåter handskakningen. Det säger ingenting om huruvida processen är en SSTP-server, om den har ett certifikat som är giltigt för namnet i din profil, eller om den kommer att auktorisera ditt konto. En webbserver på samma adress svarar perfekt på handskakningen och svarar sedan på din SSTP-förfrågan med ett HTTP-fel. Allt ovanför den handskakningen förblir otestat.

Behandla porttestet som det billigaste möjliga filtret och inte som en dom. Dess värde är att det tar bort en hel kategori fel, inte att det bekräftar allt ovanför.

Att blanda ihop de två är anledningen till att människor installerar om klienter efter ett test som aldrig undersökte klientens verkliga problem.

Separera de fyra stegen med bevis

Stegen är transportens nåbarhet, TLS-validering, SSTP-utbytet över HTTPS och PPP-autentisering inne i tunneln. En väg som klarar det första och misslyckas på det fjärde behöver en korrigering av inloggningsuppgifterna; en som misslyckas på det andra behöver en korrigering av certifikat eller namn. Dessa reparationer har inget gemensamt, och att välja fel slösar bort avbrottet.

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/

Det tredje kommandot är värt att läsa noggrant. Ett 200 från en vanlig webbsida säger att det finns en webbtjänst; det säger inte att SSTP-förfrågan kommer att förstås. Ett 404 från samma adress är lika lite informativt om VPN:n. Bara klientloggen säger vilket av de fyra stegen som nåddes.

Lägg märke till vilket namn varje kommando använde. Certifikatet väljs efter namnet du skickar, så en skillnad mellan profilen och testet är en skillnad du själv har infört. Att skriva namnet bredvid resultatet förhindrar förvirringen senare.

Läs delvis framgång i rätt riktning

En mellanhand kan tillåta vanligt surfande och neka det senare utbytet, och därför kan en proxy som fungerar för webbplatser fortfarande misslyckas för en tunnel. Samma mönster uppträder när ett certifikat är giltigt för ett webbläsarnamn men inte för namnet som konfigurerats i profilen: webbläsaren är nöjd och klienten är det inte, och båda har rätt om vad de kontrollerade.

Håll servervalideringen påslagen medan du diagnostiserar detta. Att stänga av den förvandlar en certifikatsskillnad till en lyckad handskakning och döljer det enda beviset som skulle ha förklarat felet.

Om samma profil fungerar från ett annat nätverk är skillnaden vägberoende. Det begränsar sökningen till mellanhänder utan att säga vilken, och det är fortfarande ett användbart steg framåt. Anteckna nätverket du använde, eftersom jämförelsen är värdelös utan det.

Testa sedan applikationen, inte bara sessionen

När en session finns, verifiera den avsedda rutten, namnmatchningen och tjänstbehörigheten från den klient som behöver dem. En ansluten tunnel kan fortfarande sakna vidarebefordran på den bortre sidan eller ha en returväg som aldrig fanns, och dessa fel ser exakt ut som ett applikationsproblem för personen som väntar.

Håll varje slutsats knuten till det steg som producerade den. Att kalla en öppen port för en fungerande VPN är hur en femminuterscertifikatkontroll blir en dag av ominstallation av programvara.