Port 443 svarar, SSTP feilar framleis: kva trinn braut saman?

Å fullføre eit TCP-handtrykk til port 443 medan tunnelen aldri vert bygd, provar éin ting, og det er ein liten ting. Noko lyttar og er viljug til å godta eit samband på den adressa. Det identifiserer ikkje tenesta, sertifikatet ho vil leggje fram, eller kva som skjer etter dei første byta.

Fire trinn ligg mellom det handtrykket og ein fungerande tunnel, og kvart trinn gjev ein annan feil.

Ein open port skildrar berre eitt lag

Å godta eit TCP-samband tyder at ein prosess eig sockelen og at banen tillèt handtrykket. Det seier ingenting om prosessen er ein SSTP-tenar, om han har eit sertifikat som er gyldig for namnet i profilen din, eller om han vil autorisere kontoen din. Ein webserver på same adresse svarar perfekt på handtrykket og svarar deretter på SSTP-førespurnaden din med ein HTTP-feil. Alt over det handtrykket vert utesta.

Behandle porttesten som det billegaste mogelege filteret og ikkje som ein dom. Verdien er at han fjernar ein heil kategori feil, ikkje at han stadfester alt over seg.

Å blande dei to er grunnen til at folk installerer klientar på nytt etter ein test som aldri undersøkte det verkelege problemet til klienten.

Skil dei fire trinna med prov

Trinna er tilgjenge til transport, TLS-validering, SSTP-utvekslinga over HTTPS og PPP-autentisering inne i tunnelen. Ein bane som greier den første og feilar på den fjerde, treng ein retting av påloggingsinformasjon; ein som feilar på den andre, treng ei retting av sertifikat eller namn. Desse reparasjonane har ingenting til felles, og å velje den gale sløser bort avbrotet.

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 verd å lese nøye. Ein 200 frå ei vanleg nettside fortel deg at det finst ei webteneste; det fortel deg ikkje at SSTP-førespurnaden vil verte forstått. Ein 404 frå same adresse er like lite informativ om VPN-en. Berre klientloggen fortel deg kva av dei fire trinna han nådde.

Legg merke til kva namn kvar kommando brukte. Sertifikatet vert valt etter namnet du sender, så eit avvik mellom profilen og testen er eit avvik du sjølv innførte. Å skrive det namnet ved sida av resultatet hindrar forvirringa seinare.

Les delvis suksess i rett retning

Ein mellomliggande part kan tillate vanleg surfing og nekte den seinare utvekslinga, og difor kan ein proxy som fungerer for nettstader, framleis feile for ein tunnel. Det same mønsteret viser seg når eit sertifikat er gyldig for eit nettlesarnamn men ikkje for namnet som er sett opp i profilen: nettlesaren er nøgd og klienten er ikkje, og begge har rett i det dei kontrollerte.

Hald servervalideringa på medan du diagnostiserer dette. Å slå ho av gjer eit sertifikatavvik om til eit vellukka handtrykk og skjuler det einaste provet som ville ha forklart feilen.

Viss same profil fungerer frå eit anna nettverk, er skilnaden baneavhengig. Det snevrar søket inn til mellomledd utan å seie kva, og det er framleis eit nyttig steg vidare. Noter nettverket du brukte, fordi samanlikninga er verdilaus utan det.

Test deretter applikasjonen, ikkje berre økta

Når ei økt finst, stadfest den tiltenkte ruta, namneoppslag og tenestetillating frå klienten som treng dei. Ein tilkopla tunnel kan framleis mangla vidaresending på den andre sida eller ha ei returrute som aldri fanst, og desse feila ser nøyaktig ut som eit applikasjonsproblem for personen som ventar.

Hald kvar konklusjon knytt til trinnet som produserte han. Å kalle ein open port ein fungerande VPN er korleis ein fem minutts sertifikatkontroll vert ein dag med reinstallering av programvare.