Batas waktu SSTP atau kesalahan sertifikat: cara membedakannya

Koneksi SSTP gagal dengan dua cara yang dari kursi pengguna tampak sama, dan perbaikan masing-masing berada di lapisan berbeda. Batas waktu berarti pertukaran yang diperlukan tidak pernah selesai; kesalahan sertifikat berarti materi identitas tiba dan ditolak. Memperlakukan yang kedua seperti yang pertama mengirim Anda ke firewall dan kata sandi yang tidak pernah menjadi masalah. Bukti yang membedakannya ada di log klien itu sendiri, jika Anda membacanya sebelum mengubah apa pun.

Dua kegagalan, dua pertukaran berbeda

SSTP membawa terowongan di dalam sesi berbentuk HTTPS, karena itu ia bertahan di jaringan yang hanya mengizinkan 443. Klien menyelesaikan jabat tangan TLS, mengirim permintaan HTTP dengan metode khusus protokol, lalu terowongan berjalan di dalam aliran itu. Kegagalan pada salah satu langkah itu menghentikan koneksi, dan hanya langkah berikutnya yang melibatkan kredensial.

Urutan itulah diagnosisnya. Jika jabat tangan TLS tidak pernah selesai, tidak ada kredensial yang dikirim, jadi mengatur ulang kata sandi tidak bisa menolong. Jika jabat tangan selesai lalu mandek, identitas diterima dan sesuatu di jalur permintaan menolaknya. Jika jabat tangan gagal dengan pesan validasi, server menjawab dan klien tidak menyukai apa yang didengarnya. Tiga hasil, tiga lapisan.

Baris log biasanya menyebut yang mana dari ketiganya Anda alami, karena itu mencatatnya sebelum perubahan pertama layak dilakukan.

Batas waktu berarti sebuah tahap tidak pernah selesai

Mulailah dengan resolusi nama dan keterjangkauan TCP, karena batas waktu di sana terlihat identik dengan batas waktu di kemudian hari. Pemeriksa port yang melaporkan 443 terbuka hanya membuktikan bahwa pendengar menerima koneksi, dan tidak lebih dari itu.

Tersangka berikutnya adalah jalur, bukan host. Proxy dan firewall yang mengenali aplikasi kadang menolak metode permintaan yang dipakai SSTP, atau menjatuhkan aliran yang tetap terbuka berjam-jam, dan kedua perilaku itu tampak seperti batas waktu dari sisi klien. Halaman HTTPS generik dari host yang sama termuat dengan sempurna sementara metode terowongan ditolak, karena itu menjelajah ke titik akhir hanya membuktikan sedikit. Ujilah dari jaringan tanpa proxy untuk memisahkan kedua kasus itu.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Batas waktu sebelum respons apa pun dari mitra tidak mengatakan apa pun tentang akun, dan mengganti kata sandi saat itu hanya menambah satu variabel.

Kesalahan sertifikat berarti identitas ditolak

Di sini server benar-benar menjawab, jadi jaringan bekerja dan pertanyaannya bergeser ke identitas. Bandingkan nama yang dipanggil klien dengan nama yang benar-benar dinyatakan sertifikat, lalu periksa tanggal validitas dan rantai penerbit.

CA privat yang tidak dipercaya klien menghasilkan kelas kesalahan yang sama dengan sertifikat kedaluwarsa, dan begitu juga jam yang meleset berjam-jam. Memanggil alamat mentah menciptakan ketidakcocokan baru, karena sertifikat menyatakan nama, bukan alamat. Dalam penerapan terkelola, mintalah konfigurasi kepercayaan yang dimaksud dari administratornya alih-alih menerima akar pengganti yang ditawarkan halaman kesalahan. Validasi tetap menyala selama Anda memperbaiki penyebabnya.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Biarkan tahap TLS yang berhasil tetap utuh setelah lolos, karena membatalkannya nanti menyembunyikan perubahan mana yang benar-benar memperbaiki terowongan.

Di mana keduanya tertukar

Kedua kegagalan muncul sebagai koneksi yang tidak menyala, dan keduanya datang setelah pengguna mengubah sesuatu yang tidak terkait. Kebetulan itulah yang membuat perbaikan keliru tampak masuk akal untuk sementara.

Dua kebiasaan memisahkan keduanya. Rekam log klien sebelum menyentuh konfigurasi, agar keadaan pertama terjaga. Ubah satu lapisan per percobaan, agar hasil berikutnya milik variabel yang diketahui. Pemeriksa port dan peramban adalah pengamatan sebagian, bukan urutan lengkap, dan keduanya tidak menggantikan laporan klien sendiri. Tidak ada kebiasaan yang berbiaya, dan keduanya memperpendek penyelidikan.

Pertanyaan sertifikat dan pertanyaan keterjangkauan didokumentasikan terpisah karena suatu alasan.

Uji ulang dengan klien sebenarnya, lalu bergerak ke dalam

Setelah koreksi spesifiknya terpasang, coba lagi dengan klien SSTP sebenarnya dan profil yang nyata, bukan dengan tab peramban.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Jika sesi tersambung dan sumber daya masih gagal, terowongan bukan lagi tersangkanya: lanjut ke perutean, DNS, dan akses layanan. Itu penyelidikan lain dengan bukti lain. Mempertahankan tahap TLS dan autentikasi yang bekerja mencegahnya menjadi pengulangan yang pertama. Tuliskan tahap yang gagal di tiket, karena kalau tidak orang berikutnya akan mulai dari atas lagi.