Port 443 svarer, SSTP feiler fortsatt: hvilket trinn brøt sammen?

Å fullføre et TCP-håndtrykk til port 443 mens tunnelen aldri bygges beviser én ting, og det er en liten ting. Noe lytter og er villig til å godta en forbindelse på den adressen. Det identifiserer ikke tjenesten, sertifikatet den vil presentere, eller hva som skjer etter de første bytene.

Fire trinn ligger mellom det håndtrykket og en fungerende tunnel, og hvert trinn gir en annen feil.

En åpen port beskriver bare ett lag

Å godta en TCP-forbindelse betyr at en prosess eier sockelen og at banen tillater håndtrykket. Det sier ingenting om hvorvidt den prosessen er en SSTP-server, om den har et sertifikat som er gyldig for navnet i profilen din, eller om den vil autorisere kontoen din. En webserver på samme adresse svarer perfekt på håndtrykket og svarer deretter på SSTP-forespørselen din med en HTTP-feil. Alt over det håndtrykket forblir utestet.

Behandle porttesten som det billigste mulige filteret i stedet for som en dom. Verdien er at den fjerner en hel kategori av feil, ikke at den bekrefter alt over seg.

Å forveksle de to er grunnen til at folk reinstallerer klienter etter en test som aldri undersøkte klientens faktiske problem.

Skill de fire trinnene med bevis

Trinnene er transportens tilgjengelighet, TLS-validering, SSTP-utvekslingen over HTTPS og PPP-autentisering inne i tunnelen. En bane som består den første og feiler på den fjerde, trenger en rettelse av påloggingsinformasjon; en som feiler på den andre, trenger en rettelse av sertifikat eller navn. Disse reparasjonene har ingenting til felles, og å velge den gale sløser bort avbruddet.

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 kommandoen er verdt å lese nøye. Et 200 fra en vanlig nettside forteller deg at det finnes en webtjeneste; det forteller deg ikke at SSTP-forespørselen vil bli forstått. Et 404 fra samme adresse er like lite informativt om VPN-en. Bare klientloggen forteller deg hvilket av de fire trinnene den nådde.

Legg merke til hvilket navn hver kommando brukte. Sertifikatet velges etter navnet du sender, så et avvik mellom profilen og testen er et avvik du selv innførte. Å skrive det navnet ved siden av resultatet hindrer forvirringen senere.

Les delvis suksess i riktig retning

En mellomliggende part kan tillate vanlig surfing og nekte den senere utvekslingen, og derfor kan en proxy som fungerer for nettsteder, fortsatt feile for en tunnel. Det samme mønsteret vises når et sertifikat er gyldig for et nettlesernavn men ikke for navnet som er konfigurert i profilen: nettleseren er fornøyd og klienten er ikke, og begge har rett i det de kontrollerte.

Hold servervalideringen på mens du diagnostiserer dette. Å slå den av gjør et sertifikatavvik om til et vellykket håndtrykk og skjuler det eneste beviset som ville ha forklart feilen.

Hvis samme profil fungerer fra et annet nettverk, er forskjellen banavhengig. Det snevrer søket inn til mellomledd uten å si hvilket, og det er fortsatt et nyttig skritt videre. Noter nettverket du brukte, fordi sammenligningen er verdiløs uten det.

Test deretter applikasjonen, ikke bare økten

Når en økt finnes, verifiser den tiltenkte ruten, navneoppslag og tjenestetillatelse fra klienten som trenger dem. En tilkoblet tunnel kan fortsatt mangle videresending på den andre siden eller ha en returrute som aldri fantes, og disse feilene ser nøyaktig ut som et applikasjonsproblem for personen som venter.

Hold hver konklusjon knyttet til trinnet som produserte den. Å kalle en åpen port en fungerende VPN er hvordan en fem minutters sertifikatkontroll blir en dag med reinstallering av programvare.