SSTP gagal di tempat HTTPS browser berhasil: mengapa
SSTP berjalan di dalam TLS pada port 443, tetapi itu bukan permintaan web. Uji TCP, identitas TLS, pertukaran SSTP, dan autentikasi PPP sebagai tahap terpisah.
Browser membuka nama host VPN melalui HTTPS tanpa keluhan, dan klien SSTP tetap menolak terhubung. Tidak ada yang bertentangan pada pasangan itu. SSTP memakai TLS sebagai transport luar lalu menjalankan permintaan dan muatan PPP-nya sendiri di dalam koneksi itu, sehingga pemuatan halaman yang berhasil hanya membuktikan satu hal sempit: host menjawab GET pada port 443. Klien menanyakan pertanyaan lain, dan server mungkin menjawabnya dengan buruk.
Halaman termuat dan terowongannya tidak
Orang beralih ke uji browser karena cepat, lalu menganggap hasilnya sebagai bukti bahwa server dapat dijangkau dan terkonfigurasi. Itu bukti tentang GET ke jalur mana pun yang dibuka bilah alamat, tidak lebih. Percakapan VPN dimulai setelah jabat tangan TLS yang sama, tetapi mengirim metode dan jalur yang tidak pernah dipakai halaman web. Jadi respons 200 untuk browser tidak mengatakan apa pun tentang ada atau tidaknya titik akhir SSTP.
Pisahkan kedua pengamatan dan pencarian menjadi lebih singkat. Transport dan rantai sertifikat bekerja, dan sesuatu dalam pertukaran protokol di atasnya tidak. Ini penyelidikan berbeda dari port rusak atau sertifikat kedaluwarsa, dan memerlukan bukti berbeda.
Apa yang sebenarnya dikirim klien SSTP
Klien mengirim permintaan HTTP dengan metode SSTP_DUPLEX_POST ke jalur /sra_{GUID}/, lalu menjaga badan koneksi tetap terbuka sebagai aliran dua arah yang membawa frame PPP. Server yang patuh menjawab HTTP/1.1 200 dan berhenti berperilaku seperti server web. Apa pun yang lain adalah tanda tangan: 405 atau 404 berarti titik akhirnya tidak ada, 301 atau 302 berarti sesuatu mengalihkan permintaan, dan FIN seketika berarti proksi atau server menutup aliran.
Karena itu targetnya harus server SSTP, bukan server web yang ditempeli sertifikat TLS. Metode, jalur, dan badan berumur panjang adalah persyaratan protokol, jadi proksi terbalik tidak dapat menambahkannya hanya lewat konfigurasi. Proksi yang meneruskan HTTPS biasa dengan sempurna tetap bisa menolak metode yang tidak dikenalnya.
Di mana proksi atau server web memutus aliran
Perantara memeriksa baris permintaan HTTP sebelum meneruskan apa pun, dan metode khusus dengan jalur tak biasa bisa gagal pada aturannya. Sebagian perangkat menyajikan halaman normal sambil menolak atau menyela terowongan, sehingga klien melaporkan koneksi yang dimulai lalu mati alih-alih penolakan bersih. Perangkat lain menerima permintaan, lalu menerapkan batas waktu badan atau diam yang tidak dapat ditahan keepalive PPP. Keduanya tampak sama dari sisi klien, karena itu tahap yang gagal lebih penting daripada teks kesalahan.
Berbagi port 443 antara situs web dan SSTP adalah pilihan perutean, bukan janji bahwa setiap lompatan menangani kedua percakapan dengan cara yang sama. Jika penyeimbang beban, firewall, atau terminator TLS ada di jalur, tambahkan ke daftar tersangka sebelum menyentuh konfigurasi VPN.
Uji tahapannya secara terpisah
Jalankan pemeriksaan secara berurutan dan berhenti pada kegagalan pertama, karena setiap tahap menyingkirkan lapisan yang berbeda. Probe TLS di bawah memisahkan identitas sertifikat dari apa pun yang dilakukan SSTP. Ganti nama host dengan titik akhir Anda dan baca subject serta rantai yang dicetaknya.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comLalu petakan bukti yang tersisa ke tahapan alih-alih menebak dari kesalahan klien. Tabel di bawah adalah daftar periksa untuk dikutip di tiket, dengan tanda tangan yang memisahkan satu kegagalan dari kegagalan berikutnya.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Catat tahap terakhir yang berhasil di tiket alih-alih menulis "tidak dapat terhubung". Spesifikasi MS-SSTP mendokumentasikan permintaan dan pertukaran PPP yang menyusul jabat tangan TLS, dan itulah rujukan mengapa uji browser tidak dapat menggantikan keduanya.
Identitas dulu, lalu PPP
Identitas TLS dan autentikasi PPP berurutan, bukan alternatif, dan mencampuradukkannya mengirim orang ke pengaturan server yang salah. Klien memvalidasi sertifikat server dan tujuan yang dimaksudkan lebih dulu, lalu PPP menegosiasikan keadaannya sendiri dan mengautentikasi pengguna dengan metode tantangan-respons atau EAP. Masalah sertifikat menghasilkan kesalahan yang berbeda dari kata sandi yang ditolak, dan tidak satu pun kesalahan menjelaskan tahap yang ditangani yang lain.
Mengganti nama host dengan alamat, atau mengeklik melewati peringatan sertifikat, menghapus pemeriksaan yang akan mengidentifikasi tahap yang gagal alih-alih memperbaikinya. Pertahankan peringatan itu dan bacalah. Jangan menyetel ulang kata sandi PPP ketika pertukaran HTTP tidak pernah mencapai perilaku SSTP, karena kredensialnya tidak pernah diminta.