Poort 443 antwoord, SSTP misluk steeds: watter fase het gebreek?

Die voltooiing van ’n TCP-handskud na poort 443 terwyl die tonnel nooit gebou word nie, bewys een ding, en dit is ’n klein ding. Iets luister en is bereid om ’n verbinding by daardie adres te aanvaar. Dit identifiseer nie die diens, die sertifikaat wat dit sal voorlê, of wat ná die eerste grepe gebeur nie.

Vier fases lê tussen daardie handskud en ’n werkende tonnel, en elkeen lewer ’n ander fout.

’n Oop poort beskryf net een laag

Om ’n TCP-verbinding te aanvaar beteken dat ’n proses die sokhouer besit en die pad die handskud toelaat. Dit sê niks daaroor of daardie proses ’n SSTP-bediener is, of dit ’n sertifikaat het wat vir die naam in jou profiel geldig is, of dit jou rekening sal magtig nie. ’n Webbediener op dieselfde adres antwoord die handskud perfek en reageer dan op jou SSTP-versoek met ’n HTTP-fout. Alles bo daardie handskud bly ongetoets.

Behandel die poorttoets as die goedkoopste moontlike filter, nie as ’n uitspraak nie. Die waarde daarvan is dat dit een hele kategorie foute verwyder, nie dat dit alles bo dit bevestig nie.

Verwarring van die twee is die rede waarom mense kliënte herinstalleer ná ’n toets wat nooit die kliënt se werklike probleem ondersoek het nie.

Skei die vier fases met bewyse

Die fases is vervoerbereikbaarheid, TLS-validering, die SSTP-uitruiling oor HTTPS, en PPP-verifikasie binne die tonnel. ’n Pad wat die eerste slaag en die vierde faal, het ’n regstelling van geloofsbriewe nodig; een wat die tweede faal, het ’n sertifikaat- of naamregstelling nodig. Daardie herstellings het niks gemeen nie, en die verkeerde een kies mors die onderbreking.

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/

Die derde opdrag is die moeite werd om aandagtig te lees. ’n 200 van ’n gewone webblad sê vir jou daar is ’n webdiens; dit sê nie dat die SSTP-versoek verstaan sal word nie. ’n 404 van dieselfde adres is ewe oninsiggewend oor die VPN. Net die kliëntlog sê vir jou watter van die vier fases dit bereik het.

Let op watter naam elke opdrag gebruik het. Die sertifikaat word gekies deur die naam wat jy stuur, so ’n verskil tussen die profiel en die toets is ’n verskil wat jy self ingebring het. Om daardie naam langs die resultaat te skryf, voorkom later die verwarring.

Lees gedeeltelike sukses in die regte rigting

’n Tussenparty kan gewone blaai toelaat en die latere uitruiling weier, en daarom kan ’n instaanbediener wat vir webwerwe werk steeds vir ’n tonnel faal. Dieselfde patroon verskyn wanneer ’n sertifikaat geldig is vir ’n blaaiernaam maar nie vir die naam wat in die profiel opgestel is nie: die blaaier is tevrede en die kliënt nie, en albei is korrek oor wat hulle getoets het.

Hou bediener-validering aangeskakel terwyl jy dit diagnoseer. Om dit af te skakel, verander ’n sertifikaatverskil in ’n geslaagde handskud en verberg die enigste bewys wat die fout sou verklaar.

As dieselfde profiel van ’n ander netwerk af werk, is die verskil padgebonde. Dit vernou die soektog na tussenpartye sonder om te sê watter een, en dit is steeds ’n nuttige stap vorentoe. Teken die netwerk aan wat jy gebruik het, want die vergelyking is waardeloos daarsonder.

Toets dan die toepassing, nie net die sessie nie

Sodra ’n sessie bestaan, verifieer die beoogde roete, naamresolusie en diensregte vanaf die kliënt wat dit nodig het. ’n Gekoppelde tonnel kan steeds ontbrekende deurverwysing aan die ander kant hê of ’n terugroete wat nooit bestaan het nie, en daardie foute lyk presies soos ’n toepassingsprobleem vir die persoon wat wag.

Hou elke gevolgtrekking gekoppel aan die fase wat dit opgelewer het. Om ’n oop poort ’n werkende VPN te noem, is hoe ’n sertifikaattoets van vyf minute ’n dag van sagteware herinstalleer word.