SSTP mengesahkan pelayan dahulu dan pengguna kemudian

Klien SSTP boleh melengkapkan TLS dan masih menolak pengguna sesaat kemudian. Urutan itu bukan pepijat, ia ialah tindanan protokol: keselamatan pengangkutan dahulu, pengesahan pengguna kemudian. Oleh sebab kedua-dua peringkat gagal dengan mesej berbeza, ia juga memerlukan pembaikan berbeza. Membaca peringkat mana yang menghasilkan ralat ialah sebahagian besar diagnosis.

Sijil yang dipercayai membuktikan titik akhir; ia tidak mengatakan apa-apa tentang akaun.

Apa yang ditetapkan oleh jabat tangan TLS

Klien mengesahkan sijil yang dikemukakan oleh pelayan terhadap stor kepercayaannya, nama hos yang diminta, tetingkap kesahihan dan sebarang dasar tambahan yang digunakan oleh platform. Itu melindungi sambungan ke titik akhir yang dimaksudkan. Ia tidak membuktikan bahawa akaun tertentu didayakan, belum tamat tempoh atau dibenarkan menggunakan akses jauh. Itu soalan berasingan yang ditanya kemudian oleh komponen lain.

Sebab itulah membuang semakan sijil untuk sampai ke gesaan log masuk ialah pembaikan yang salah. Anda mendapat gesaan log masuk pada sambungan yang tidak dapat anda sahkan. Ralat sijil tergolong dalam nama hos, jam, rantai atau konfigurasi kepercayaan.

Apa yang ditambah oleh SSTP dan PPP di atasnya

SSTP berjalan melalui HTTPS dan membawa PPP di dalamnya, dengan pertukaran kawalannya sendiri di sekeliling sambungan. PPP kemudian menjalankan fasa pautan dan pengesahannya, dan kaedah pengesahan bergantung pada dasar pelayan dan keupayaan klien. PAP, CHAP, MS-CHAPv2 dan EAP semuanya pilihan pengesahan PPP dengan sifat yang sangat berbeza. Semakan pengguna VPN ialah fasa PPP itu, bukan lapisan TLS di bawahnya.

Penolakan pengguna boleh bermakna kelayakan, sekatan akaun atau ketidakpadanan kaedah.

Sebab di pihak pelayan jauh lebih berguna daripada menetapkan semula setiap rahsia dalam profil. Peristiwa akaun dilumpuhkan dan kegagalan rundingan kaedah kelihatan serupa pada klien dan tidak mempunyai apa-apa persamaan pada pelayan.

Padankan ralat dengan peringkat

Periksa sama ada sambungan mencapai TLS, kemudian pertukaran HTTP SSTP, kemudian fasa PPP. Kekalkan cap masa log sejajar merentas percubaan supaya kegagalan terdahulu tidak dikelirukan dengan kejayaan kemudian. Klien yang merekodkan dua percubaan dalam satu tetingkap akan kelihatan gagal pada peringkat terakhir yang dicapainya. Baca ralat pertama yang berkaitan, bukan baris terakhir.

Penjajaran yang sama penting di pihak pelayan, di mana rekod pengesahan dan log pengangkutan selalunya fail berasingan dengan jam berasingan. Dua minit sisihan cukup untuk membuat sebab yang jelas kelihatan mustahil.

Selepas log masuk, kebenaran masih berasingan

Log masuk yang berjaya tidak memberi setiap sumber peribadi. Laluan menentukan apa yang boleh dicapai, DNS menentukan apa yang diselesaikan, dan setiap perkhidmatan masih menggunakan kebenarannya sendiri. Sesi yang dipaparkan bersambung ialah kenyataan tentang terowong, bukan tentang perkongsian fail. Apabila pengguna boleh bersambung dan tidak boleh mencapai satu hos, fasa terowong sudah selesai.

Itu ialah lapisan yang sama seperti yang ditunjukkan oleh jabat tangan, satu tahap lebih tinggi.

Kekalkan pemulihan akaun dalam proses yang disokong oleh pengendali dan bukan menukar tetapan pengangkutan sebagai tindak balas kepada penolakan pengguna yang jelas. Menukar pengangkutan untuk membaiki akaun yang dilumpuhkan ialah jenis pembaikan yang kelihatan berkesan apabila akaun didayakan semula atas sebab yang tidak berkaitan.