Pordo 443 respondas, SSTP ankoraŭ fiaskas: kiu etapo rompiĝis?
Io akceptis la konekton kaj la tunelo tamen ne konstruiĝas. Apartigu transporton, atestilon, SSTP-traktadon kaj PPP-aŭtentikigon.
Kompletigi TCP-manpremon al pordo 443 dum la tunelo neniam konstruiĝas pruvas unu aferon, kaj ĝi estas malgranda afero. Io aŭskultas kaj pretas akcepti konekton ĉe tiu adreso. Ĝi ne identigas la servon, la atestilon, kiun ĝi prezentos, nek kio okazas post la unuaj bajtoj.
Kvar etapoj staras inter tiu manpremo kaj funkcianta tunelo, kaj ĉiu produktas alian eraron.
Malfermita pordo priskribas nur unu tavolon
Akcepti TCP-konekton signifas, ke procezo posedas la ingon kaj la vojo permesas la manpremon. Ĝi diras nenion pri tio, ĉu tiu procezo estas SSTP-servilo, ĉu ĝi havas atestilon validan por la nomo en via profilo, aŭ ĉu ĝi rajtigos vian konton. Reta servilo ĉe la sama adreso respondas perfekte al la manpremo kaj poste respondas al via SSTP-peto per HTTP-eraro. Ĉio super tiu manpremo restas netestita.
Traktu la pordan teston kiel la plej malmultekostan eblan filtron, ne kiel verdikton. Ĝia valoro estas, ke ĝi forigas tutan kategorion de fiaskoj, ne ke ĝi konfirmas ĉion super ĝi.
Konfuzi la du estas la kialo, kial homoj reinstalas klientojn post testo, kiu neniam ekzamenis la efektivan problemon de la kliento.
Apartigu la kvar etapojn per pruvoj
La etapoj estas atingeblo de transporto, TLS-validigo, la SSTP-interŝanĝo super HTTPS kaj PPP-aŭtentikigo ene de la tunelo. Vojo, kiu trapasas la unuan kaj fiaskas ĉe la kvara, bezonas korektadon de akreditiloj; tiu, kiu fiaskas ĉe la dua, bezonas korektadon de atestilo aŭ nomo. Tiuj riparoj havas nenion komunan, kaj elekti la malĝustan malŝparas la interrompon.
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/
La tria komando indas esti legata zorgeme. 200 de ordinara retpaĝo diras al vi, ke reta servo ekzistas; ĝi ne diras, ke la SSTP-peto estos komprenita. 404 de la sama adreso estas same seninforma pri la VPN. Nur la klienta protokolo diras al vi, kiun el la kvar etapoj ĝi atingis.
Rimarku, kiun nomon ĉiu komando uzis. La atestilo estas elektata laŭ la nomo, kiun vi sendas, do malkongruo inter la profilo kaj la testa estas malkongruo, kiun vi enkondukis. Skribi tiun nomon apud la rezulto malhelpas la konfuzon poste.
Legu partan sukceson en la ĝusta direkto
Peranto povas permesi ordinaran retumadon kaj rifuzi la postan interŝanĝon, kaj tial prokurilo, kiu funkcias por retejoj, ankoraŭ povas fiaski por tunelo. La sama ŝablono aperas, kiam atestilo estas valida por retumila nomo sed ne por la nomo agordita en la profilo: la retumilo estas kontenta kaj la kliento ne, kaj ambaŭ pravas pri tio, kion ili kontrolis.
Tenu servilan validigon ŝaltita dum vi diagnozas ĉi tion. Malŝalti ĝin transformas atestilan malkongruon en sukcesan manpremon kaj kaŝas la solan pruvon, kiu klarigus la fiaskon.
Se la sama profilo funkcias el alia reto, la diferenco dependas de la vojo. Tio mallarĝigas la serĉon al perantoj sen diri kiun, kaj ĝi estas ankoraŭ utila paŝo antaŭen. Notu la reton, kiun vi uzis, ĉar la komparo estas senvalora sen ĝi.
Poste testu la aplikaĵon, ne nur la seancon
Unufoje ekzistas seanco, kontrolu la celitan vojon, nomrezolucion kaj servpermeson de la kliento, kiu bezonas ilin. Konektita tunelo ankoraŭ povas havi mankan plusendadon ĉe la fora flanko aŭ revenan vojon, kiu neniam ekzistis, kaj tiuj fiaskoj aspektas ĝuste kiel aplikaĵa problemo por la persono, kiu atendas.
Tenu ĉiun konkludon ligita al la etapo, kiu produktis ĝin. Nomi malfermitan pordon funkcianta VPN estas la maniero, per kiu kvinminuta atestila kontrolo fariĝas tago da reinstalado de programaro.