SSTP gagal di tempat HTTPS pelayar berjaya: mengapa
SSTP berjalan di dalam TLS pada port 443, tetapi ia bukan permintaan web. Uji TCP, identiti TLS, pertukaran SSTP dan pengesahan PPP sebagai peringkat berasingan.
Pelayar membuka nama hos VPN melalui HTTPS tanpa aduan, dan klien SSTP masih enggan menyambung. Tiada apa-apa yang bercanggah pada pasangan itu. SSTP menggunakan TLS sebagai pengangkutan luar dan kemudian menjalankan permintaannya sendiri serta muatan PPP di dalam sambungan itu, jadi pemuatan halaman yang berjaya hanya membuktikan satu perkara kecil: hos menjawab GET pada port 443. Klien bertanya soalan lain, dan pelayan mungkin menjawabnya dengan buruk.
Halaman dimuatkan dan terowong tidak
Orang beralih kepada ujian pelayar kerana ia pantas, kemudian menganggap hasilnya sebagai bukti bahawa pelayan boleh dicapai dan dikonfigurasikan. Ia bukti tentang GET ke laluan yang dibuka oleh bar alamat, tidak lebih. Perbualan VPN bermula selepas jabat tangan TLS yang sama, tetapi menghantar kaedah dan laluan yang tidak pernah digunakan oleh halaman web. Jadi respons 200 kepada pelayar tidak berkata apa-apa tentang sama ada titik akhir SSTP wujud.
Asingkan dua pemerhatian dan carian menjadi lebih pendek. Pengangkutan dan rantaian sijil berfungsi, dan sesuatu dalam pertukaran protokol di atasnya tidak berfungsi. Ini siasatan berbeza daripada port rosak atau sijil tamat tempoh, dan ia memerlukan bukti berbeza.
Apa yang sebenarnya dihantar oleh klien SSTP
Klien menghantar permintaan HTTP dengan kaedah SSTP_DUPLEX_POST ke laluan /sra_{GUID}/, kemudian membiarkan badan sambungan terbuka sebagai aliran dua hala yang membawa bingkai PPP. Pelayan yang patuh menjawab HTTP/1.1 200 dan berhenti berkelakuan seperti pelayan web. Apa-apa lagi ialah tandatangan: 405 atau 404 bermakna titik akhir tiada, 301 atau 302 bermakna sesuatu mengubah hala permintaan, dan FIN segera bermakna proksi atau pelayan menutup aliran.
Sebab itu sasaran mesti pelayan SSTP dan bukan pelayan web yang ditempel sijil TLS. Kaedah, laluan dan badan jangka panjang ialah keperluan protokol, jadi proksi songsang tidak boleh menambahnya dengan konfigurasi sahaja. Proksi yang memajukan HTTPS biasa dengan sempurna masih boleh menolak kaedah yang tidak dikenalnya.
Di mana proksi atau pelayan web memutuskan aliran
Perantara memeriksa baris permintaan HTTP sebelum memajukan apa-apa, dan kaedah tersuai dengan laluan luar biasa mungkin gagal pada peraturannya. Sesetengah peranti menyajikan halaman biasa sambil menolak atau mengganggu terowong, jadi klien melaporkan sambungan yang bermula lalu mati dan bukannya penolakan bersih. Yang lain menerima permintaan, kemudian menggunakan had masa badan atau melahu yang tidak dapat ditahan oleh keepalive PPP. Kedua-duanya kelihatan sama dari sisi klien, sebab itu peringkat yang gagal lebih penting daripada teks ralat.
Berkongsi port 443 antara laman web dan SSTP ialah pilihan penghalaan, bukan janji bahawa setiap hop mengendalikan kedua-dua perbualan dengan cara yang sama. Jika penyeimbang beban, tembok api atau penamat TLS berada di laluan, tambahkannya ke senarai suspek sebelum menyentuh konfigurasi VPN.
Uji peringkat secara berasingan
Jalankan pemeriksaan mengikut urutan dan berhenti pada kegagalan pertama, kerana setiap peringkat mengecualikan lapisan berbeza. Prob TLS di bawah memisahkan identiti sijil daripada apa-apa yang SSTP lakukan. Gantikan nama hos dengan titik akhir anda dan baca subject serta rantaian yang dicetaknya.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comKemudian petakan bukti yang tinggal kepada peringkat dan bukannya meneka daripada ralat klien. Jadual di bawah ialah senarai semak untuk dipetik dalam tiket, dengan tandatangan yang memisahkan satu kegagalan daripada yang seterusnya.
| 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 peringkat terakhir yang berjaya dalam tiket dan bukannya menulis "tidak dapat menyambung". Spesifikasi MS-SSTP mendokumentasikan permintaan dan pertukaran PPP yang menyusuli jabat tangan TLS, dan itulah rujukan mengapa ujian pelayar tidak boleh menggantikan mana-mana daripadanya.
Identiti dahulu, kemudian PPP
Identiti TLS dan pengesahan PPP adalah berurutan, bukan alternatif, dan mengelirukannya membawa orang ke tetapan pelayan yang salah. Klien mengesahkan sijil pelayan dan tujuan yang dimaksudkan dahulu, kemudian PPP merundingkan keadaannya sendiri dan mengesahkan pengguna dengan kaedah cabaran-respons atau EAP. Masalah sijil menghasilkan ralat berbeza daripada kata laluan ditolak, dan tiada satu pun ralat menerangkan peringkat yang diliputi oleh yang lain.
Menggantikan nama hos dengan alamat, atau mengklik melepasi amaran sijil, membuang pemeriksaan yang akan mengenal pasti peringkat yang gagal dan bukannya membaikinya. Kekalkan amaran itu dan bacalah. Jangan tetapkan semula kata laluan PPP apabila pertukaran HTTP tidak pernah mencapai tingkah laku SSTP, kerana kelayakan itu tidak pernah diminta.