SSTP adalah PPP di atas HTTPS, bukan halaman web di port 443

SSTP membawa PPP di dalam koneksi HTTPS, itulah sebabnya ia tampak seperti lalu lintas web bagi apa pun di tengah. TLS dan HTTP membangun kanal luar, lalu pesan kendali SSTP menyiapkan terowongan, dan PPP menyediakan perilaku sesi. Peramban yang memuat halaman di alamat yang sama hanya menyelesaikan sebagian tahap pertama. Menganggapnya sebagai uji VPN adalah cara proxy yang berfungsi disalahkan atas ketidakcocokan protokol.

Telusuri keempat tahap secara berurutan, dan kegagalan yang Anda lihat akan jatuh di salah satunya.

Tahap 1: TCP dan TLS

Klien membuka koneksi TCP ke port 443 dan melakukan jabat tangan TLS. Rantai sertifikat harus cocok dengan nama host yang dipakai saat klien dikonfigurasi. Ketidakcocokan nama di sini menghasilkan kegagalan sebelum pesan SSTP apa pun dipertukarkan, dan spesifikasi SSTP mengasumsikan kanal HTTPS luar ini sudah ada. Tidak ada apa pun di tahap berikutnya yang bisa menutupi kegagalan kepercayaan di sini.

Server web umum dapat menyelesaikan tahap ini dengan sempurna dan tetap gagal di tahap berikutnya. Keberhasilan TLS adalah bukti tentang sertifikat, bukan tentang protokol di baliknya.

Tahap 2: permintaan HTTPS

SSTP mengirim permintaannya dengan metode khusus, SSTP_DUPLEX_POST, dan membiarkan pertukaran tetap terbuka alih-alih mengembalikan dokumen. Server atau proxy yang dikonfigurasi untuk permintaan halaman biasa dapat menerima koneksi lalu menolak metodenya. Penolakan itu adalah masalah kompatibilitas yang biasanya digambarkan orang sebagai port 443 diblokir.

Baca kode respons dan metode di log server. Penolakan pada tahap ini adalah masalah yang berbeda dari batas waktu TCP, dan keduanya mengarah ke perbaikan yang berbeda.

Tahap 3: pesan kendali

Setelah permintaan diterima, SSTP mempertukarkan pesan kendali yang menegosiasikan dan menyiapkan terowongan. Ini pesan protokol di dalam badan HTTPS, bukan permintaan HTTP, jadi proxy yang memeriksa dan menulis ulang badan dapat merusaknya sementara permintaan halaman tetap utuh.

Di sinilah kotak tengah inspeksi mendalam mendapatkan reputasinya. Jika halaman dimuat tetapi VPN gagal, periksa apakah badannya diubah, bukan apakah portnya terbuka.

Tahap 4: PPP mengambil alih

PPP kemudian menyediakan perilaku sesi: negosiasi tautan, autentikasi, dan konfigurasi lapisan jaringan yang menyusul. Autentikasi PPP terpisah dari pemeriksaan TLS yang sudah dilewati klien. Sertifikat server yang diterima klien tidak mengatakan apa pun tentang apakah kredensial pengguna valid atau akunnya diotorisasi.

Sertifikat yang diterima dan login yang ditolak tidak saling bertentangan. Itu tahap berurutan dengan hasil yang independen.

Autentikasi memiliki beberapa peran

Klien memvalidasi identitas server TLS terhadap penyimpanan kepercayaannya dan nama yang dikonfigurasi. Lalu PPP mengautentikasi pengguna atau mesin, tergantung penerapannya. Server dapat menambahkan kebijakannya sendiri tentang siapa yang boleh terhubung dan apa yang boleh dicapai. Jaga nama host tetap konsisten dengan identitas sertifikat, karena menggantinya dengan alamat mentah mengubah penyiapan yang berfungsi menjadi kegagalan pemeriksaan nama.

Catat tahap mana yang melaporkan kegagalan. Sertifikat, metode, pesan kendali, autentikasi PPP, lalu rute: lima tempat, lima perbaikan.

Apa yang bisa dan tidak bisa ditunjukkan uji peramban

Memuat halaman di alamat itu membuktikan resolusi DNS, keterjangkauan TCP, dan ada sesuatu yang mendengarkan dan berbicara HTTP. Itu tidak membuktikan metode diterima, pertukaran kendali bertahan, atau autentikasi PPP dikonfigurasi. Gunakan klien yang mengimplementasikan SSTP alih-alih mengonversi profil lain dengan mengubah port.

Setelah sesi naik, rute, DNS, dan penerusan sisi server tetap menentukan apa yang bisa dicapai pengguna. Terowongan adalah jalur, bukan otorisasi.