SSTP membawa PPP di dalam sambungan HTTPS, sebab itulah ia kelihatan seperti trafik web kepada apa sahaja di tengah. TLS dan HTTP membina saluran luar, kemudian mesej kawalan SSTP menyediakan terowong, dan PPP menyediakan tingkah laku sesi. Pelayar yang memuatkan halaman pada alamat yang sama hanya menyelesaikan sebahagian peringkat pertama. Menganggapnya ujian VPN ialah cara proksi yang berfungsi dipersalahkan atas ketidakpadanan protokol.

Telusuri keempat-empat peringkat mengikut urutan, dan kegagalan yang anda lihat akan jatuh dalam salah satunya.

Peringkat 1: TCP dan TLS

Klien membuka sambungan TCP ke port 443 dan melakukan jabat tangan TLS. Rantaian sijil mesti sepadan dengan nama hos yang digunakan semasa klien dikonfigurasikan. Ketidakpadanan nama di sini menghasilkan kegagalan sebelum sebarang mesej SSTP ditukar, dan spesifikasi SSTP menganggap saluran HTTPS luar ini sudah wujud. Tiada apa-apa pada peringkat kemudian yang boleh menampung kegagalan kepercayaan di sini.

Pelayan web biasa boleh menyelesaikan peringkat ini dengan sempurna dan masih gagal pada peringkat seterusnya. Kejayaan TLS ialah bukti tentang sijil, bukan tentang protokol di belakangnya.

Peringkat 2: permintaan HTTPS

SSTP membuat permintaannya dengan kaedah khusus, SSTP_DUPLEX_POST, dan membiarkan pertukaran terbuka daripada memulangkan dokumen. Pelayan atau proksi yang dikonfigurasikan untuk permintaan halaman biasa mungkin menerima sambungan itu dan kemudian menolak kaedah tersebut. Penolakan itu ialah masalah keserasian yang biasanya digambarkan orang sebagai port 443 disekat.

Baca kod respons dan kaedah dalam log pelayan. Penolakan pada peringkat ini ialah masalah berbeza daripada tamat masa TCP, dan kedua-duanya membawa kepada pembetulan berbeza.

Peringkat 3: mesej kawalan

Setelah permintaan diterima, SSTP menukar mesej kawalan yang merunding dan menyediakan terowong. Ini mesej protokol di dalam badan HTTPS, bukan permintaan HTTP, jadi proksi yang memeriksa dan menulis semula badan boleh memecahkannya sementara permintaan halaman kekal tidak tersentuh.

Di sinilah kotak tengah pemeriksaan mendalam mendapat reputasinya. Jika halaman dimuatkan tetapi VPN gagal, periksa sama ada badannya diubah, bukan sama ada port terbuka.

Peringkat 4: PPP mengambil alih

PPP kemudian menyediakan tingkah laku sesi: rundingan pautan, pengesahan dan konfigurasi lapisan rangkaian yang menyusul. Pengesahan PPP berasingan daripada pemeriksaan TLS yang sudah dilalui klien. Sijil pelayan yang diterima klien tidak mengatakan apa-apa tentang sama ada kelayakan pengguna sah atau akaun dibenarkan.

Sijil yang diterima dan log masuk yang ditolak tidak bercanggah. Itu peringkat berturutan dengan hasil yang bebas.

Pengesahan mempunyai beberapa peranan

Klien mengesahkan identiti pelayan TLS terhadap stor kepercayaannya dan nama yang dikonfigurasikan. Kemudian PPP mengesahkan pengguna atau mesin, bergantung pada penggunaan. Pelayan boleh menambah dasarnya sendiri tentang siapa yang boleh menyambung dan apa yang boleh dicapai. Kekalkan nama hos selaras dengan identiti sijil, kerana menggantikannya dengan alamat mentah menukar persediaan yang berfungsi menjadi kegagalan pemeriksaan nama.

Catat peringkat mana yang melaporkan kegagalan. Sijil, kaedah, mesej kawalan, pengesahan PPP, kemudian laluan: lima tempat, lima pembetulan.

Apa yang boleh dan tidak boleh ditunjukkan oleh ujian pelayar

Memuatkan halaman pada alamat itu membuktikan penyelesaian DNS, kebolehcapaian TCP dan ada sesuatu yang mendengar dan bercakap HTTP. Ia tidak membuktikan kaedah diterima, pertukaran kawalan bertahan atau pengesahan PPP dikonfigurasikan. Gunakan klien yang melaksanakan SSTP daripada menukar profil lain dengan mengubah port.

Setelah sesi naik, laluan, DNS dan penghantaran sebelah pelayan masih menentukan apa yang boleh dicapai pengguna. Terowong ialah laluan, bukan kebenaran.

Artikel berkaitan