Cara memeriksa apakah klien VPN benar-benar mendukung SSTP

Menyebut produk sebagai klien VPN tidak menjelaskan apakah produk itu berbicara SSTP, dan port 443 di alamat membuktikan lebih sedikit lagi. SSTP menjalankan TLS di atas TCP 443, lalu pertukaran kendali SSTP, lalu PPP untuk tautan itu sendiri, dengan validasi sertifikat dan metode autentikasi PPP di atasnya. Klien hanya mendukung protokol tersebut bila implementasi yang disebutkan, pada versi yang terpasang, menyelesaikan setiap lapisan itu sesuai persyaratan server Anda. Lakukan pemeriksaan di bawah ini secara berurutan dan berhenti pada yang pertama gagal, karena itulah yang layak diselesaikan.

Samakan implementasi, versi, dan platform

Mulai dari platform, aplikasi, dan build yang terpasang, karena satu nama vendor bisa berada di atas dua implementasi yang sama sekali berbeda. Jenis VPN bawaan dan klien pihak ketiga bukan hal yang sama, dan plugin dapat menampilkan label adaptor yang tidak menggambarkan protokol di bawahnya. Dokumentasi untuk rilis saat ini tidak menggambarkan build yang berjalan di mesin di depan Anda. Baca halaman khusus versi itu, lalu bandingkan dengan apa yang klien laporkan tentang dirinya sendiri.

Di Windows jenis terowongan berasal dari platform, bukan dari GUI, jadi tanyakan pada platform. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress menampilkan Sstp saat klien asli akan mencoba protokol itu, dan referensi jenis koneksi mencantumkannya di antara jenis terowongan bawaan. Di Linux tidak ada klien SSTP asli sama sekali, sehingga pertanyaannya menjadi apakah implementasi terpisah seperti sstpc dari paket sstp-client terpasang dan mutakhir.

Baca format profil sebelum label

Profil tidak dapat dipertukarkan, dan berkas yang diberikan kepada Anda biasanya menjawab pertanyaan itu lebih cepat daripada daftar fitur mana pun. Direktif OpenVPN, kunci WireGuard, dan pengaturan koneksi SSTP menggambarkan tiga protokol yang tidak berhubungan, dan tidak ada dialog impor yang mengubah satu menjadi yang lain. Berbagi port TCP 443 tidak menerjemahkan apa pun, karena SSTP, OpenVPN di atas TLS, dan layanan HTTPS biasa dapat menempati port yang sama dan tidak memiliki kesamaan di atasnya.

Jika berkasnya adalah .ovpn atau konfigurasi WireGuard, jawabannya sudah jelas: klien itu tidak diminta berbicara SSTP. Mengimpornya ke klien yang hanya bisa SSTP gagal pada tahap profil, jauh sebelum negosiasi protokol apa pun dimulai.

Apa yang tidak dibuktikan TLS tentang penerapan

Jabat tangan TLS yang selesai membuktikan server memiliki sertifikat, dan tidak membuktikan apa pun tentang apakah klien Anda memercayai rantai penerbit atau mencocokkan nama di dalamnya. Validasi harus berhasil terhadap server yang dimaksud, termasuk CA privat apa pun yang dijalankan organisasi, dan klien yang menawarkan melewati galat sertifikat telah menghapus pemeriksaan itu, bukan memperoleh dukungan protokol. Validasi rantai dan pencocokan nama adalah dua uji terpisah, dan tumpukan yang lolos satu masih bisa gagal pada yang lain. Keduanya termasuk kriteria penerimaan, bukan lampiran pemecahan masalah.

Lalu pastikan metode autentikasi PPP, karena penerapan dengan EAP-TLS memerlukan klien yang dapat menyerahkan sertifikat di dalam PPP, sedangkan metode berbasis kata sandi memerlukan dukungan untuk pertukaran itu. Alamat server dan kata sandi tidak menggambarkan kebutuhan nyata organisasi, terutama bila ada faktor kedua atau pemeriksaan perangkat di depannya. Tanyakan metode mana yang diberlakukan server sebelum menganggap klien dapat memenuhinya.

Ikuti sesi melalui empat tahap

Perhatikan koneksi melewati empat batas: TCP dan TLS ke server, pertukaran kendali SSTP, negosiasi PPP, lalu sumber daya yang benar-benar Anda butuhkan. Log yang berhenti setelah TLS menggambarkan gangguan berbeda dari log yang berhenti di dalam PPP, dan keduanya mengarah ke pemilik berbeda. Peramban yang memuat halaman web host hanya membuktikan ada sesuatu yang menjawab pada 443, yang merupakan positif palsu paling umum di bidang ini. Jika halaman itu termuat sementara klien masih gagal, masalahnya berada di atas TLS dan server web bukan tersangkanya.

Akhiri dengan sumber daya privat sungguhan dan pencarian nama, karena sesi yang terbentuk dan tidak membawa apa pun tampak sama dengan yang berfungsi di sebagian besar jendela status. Satu permintaan berhasil ke sumber daya yang Anda butuhkan menyelesaikan pertanyaan yang tidak dapat dijawab ikon.

Bila dukungan tidak ada, ubah rencana

Jika klien tidak dapat berbicara SSTP, dapatkan alternatif yang disetujui atau minta pemilik server protokol yang didukung kedua ujung. Menghapus opsi yang tidak dikenal sampai impor berhasil menghasilkan profil yang tidak tersambung ke apa pun, yaitu jalan yang lebih lambat menuju jalan buntu yang sama. Pemasang dari sumber tak dikenal yang mengiklankan kompatibilitas universal menambahkan jalur kepercayaan yang tidak disetujui ke mesin dan sering mengganti klien platform dengan sesuatu yang tidak dapat diperbarui organisasi. Tidak satu pun dari keduanya merupakan perbaikan, dan keduanya lebih sulit dibatalkan daripada masalah aslinya.

Tangani pertanyaan kompatibilitas terpisah dari kinerja dan pemilihan titik akhir, karena server terdekat tidak berguna bila klien tidak dapat berbicara protokolnya. Penyetelan latensi tidak memperbaiki tahap yang tidak pernah selesai.