Poarte 443 antwurdet, SSTP mislearret noch: hokker stap bruts?

It foltôgjen fan in TCP-hânskieding nei poarte 443 wylst de tunnel nea boud wurdt, bewiist ien ding, en it is in lyts ding. Iets harket en is ree om in ferbining op dat adres oan te nimmen. It identifisearret net de tsjinst, it sertifikaat dat it presintearje sil, of wat der nei de earste bytes bart.

Fjouwer stappen lizze tusken dy hânskieding en in wurkjende tunnel, en elk produsearret in oare flater.

In iepen poarte beskriuwt mar ien laach

It akseptearjen fan in TCP-ferbining betsjut dat in proses de socket besit en it paad de hânskieding talit. It seit neat oer de fraach oft dat proses in SSTP-tsjinner is, oft it in sertifikaat hat dat jildich is foar de namme yn jo profyl, of oft it jo akkount autorisearret. In webserver op itselde adres beantwurdet de hânskieding perfekt en reagearret dan op jo SSTP-fersyk mei in HTTP-flater. Alles boppe dy hânskieding bliuwt ûnteste.

Besjoch de poartetest as it goedkeapste mooglike filter en net as in fûnis. De wearde derfan is dat it in hiele kategory flaters fuorthellet, net dat it alles boppe him befêstiget.

It trochelkoar heljen fan de twa is de reden wêrom't minsken kliïnten opnij ynstallearje nei in test dy't it echte probleem fan de kliïnt nea ûndersocht hat.

Skied de fjouwer stappen mei bewizen

De stappen binne berikberens fan ferfier, TLS-falidaasje, de SSTP-útwikseling oer HTTPS en PPP-autentikaasje binnen de tunnel. In paad dat de earste trochstiet en by de fjirde mislearret, hat in korreksje fan oanmeldgegevens nedich; ien dat by de twadde mislearret, hat in korreksje fan sertifikaat of namme nedich. Dy reparaasjes hawwe neat mienskiplik, en de ferkearde kieze fergriemt de ûnderbrekking.

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/

It tredde kommando is it wurdich om soarchfâldich te lêzen. In 200 fan in gewoane webside fertelt jo dat der in webstsjinst is; it fertelt jo net dat it SSTP-fersyk begrepen wurde sil. In 404 fan itselde adres is like min ynformearjend oer de VPN. Allinne it kliïntlogboek fertelt jo hokker fan de fjouwer stappen it berikt hat.

Tink derom hokker namme elk kommando brûkte. It sertifikaat wurdt keazen troch de namme dy't jo stjoere, dus in ôfwiking tusken it profyl en de test is in ôfwiking dy't jo sels yntrodusearre hawwe. It skriuwen fan dy namme njonken it resultaat foarkomt letter de betizing.

Lês partiel sukses yn de juste rjochting

In tuskenpersoan kin gewoan browsen tastean en de lettere útwikseling wegerje, en dêrom kin in proxy dy't foar websiden wurket noch mislearje foar in tunnel. Itselde patroan ferskynt as in sertifikaat jildich is foar in browsernamme mar net foar de namme dy't yn it profyl konfigurearre is: de browser is tefreden en de kliïnt net, en beide hawwe gelyk oer wat se kontrolearre hawwe.

Hâld sertifikaasje fan de tsjinner ynskeakele wylst jo dit diagnostisearje. It útskeakeljen derfan feroaret in sertifikaatôfwiking yn in slagge hânskieding en ferberget it iennige bewiis dat de flater ferklearje soe.

As itselde profyl fan in oar netwurk wurket, is it ferskil paadôfhinklik. Dat beheint it sykjen ta tuskenpersoanen sûnder te sizzen hokker, en it is noch altyd in nuttige stap foarút. Notearje it netwurk dat jo brûkten, want de fergeliking is weardeleas sûnder it.

Test dan de applikaasje, net allinnich de sesje

As der in sesje bestiet, ferifiearje dan de bedoelde rûte, namme-oplossing en tsjinstpermisje fan de kliïnt dy't se nedich hat. In ferbûne tunnel kin noch in ûntbrekkende trochstjoering oan de fiere kant hawwe of in weromrûte dy't nea bestien hat, en dy flaters lykje foar de wachtjende persoan krekt as in applikaasjeprobleem.

Hâld elke konklúzje ferbûn oan de stap dy't him produsearre hat. In iepen poarte in wurkjende VPN neame is hoe't in sertifikaatkontrôle fan fiif minuten in dei fan software opnij ynstallearje wurdt.