Profil terkunci server gagal di balik proxy TLS: generasi mana?

Satu pengguna bisa terhubung dan yang lain tidak, melalui portal yang sama, pada hari yang sama. Keduanya memiliki profil terkunci server, keduanya berada pada build Access Server yang sama, dan satu-satunya perbedaan adalah kapan profil mereka dibuat. Itulah pola yang layak dikenali, karena "terkunci server" menamai kebijakan, bukan urutan koneksi. Access Server telah mengirimkan dua generasi artefak itu, dan proxy balik TLS hanya berdiri di depan salah satu jalurnya. Tiga kondisi menentukan cabang mana Anda berada.

Dua generasi, dua urutan koneksi

Pada desain lama, yang berlaku hingga 2.8, berkas yang diimpor adalah pseudo-profil. OpenVPN Connect memakainya untuk mengautentikasi ke API web Access Server melalui HTTPS, menerima profil sementara terkunci pengguna dan token sesi, dan baru kemudian membangun VPN. Dua transport berjalan berurutan, dan yang pertama adalah permintaan web biasa.

Format yang diperkenalkan dengan 2.9 tidak melakukan bootstrap per koneksi itu. Ini profil asli yang dapat digunakan oleh OpenVPN klien yang kompatibel, bukan hanya OpenVPN Connect. Mengunduhnya atau mengimpornya melalui URL masih dapat melibatkan HTTPS — itu langkah penerbitan, bukan pengambilan profil sementara per koneksi.

Peningkatan versi tidak selalu menulis ulang profil yang sudah diterbitkan, jadi versi server saat ini masih dapat membagikan artefak lama. Build server memberi tahu Anda apa yang mungkin, bukan apa yang diimpor pengguna ini.

Tiga kondisi yang memilih cabang Anda

Kondisi pertama adalah generasi artefak. Minta berkasnya, lihat bagaimana ia dihasilkan, dan catat versi klien yang mengimpornya. Jika Anda tidak dapat menetapkan generasinya dari berkas, profil baru yang diterbitkan untuk akun uji akan memberi tahu Anda apa yang dihasilkan server hari ini, dan itu informasi berbeda dari yang dimiliki pengguna yang gagal.

Kondisi kedua adalah apa yang sebenarnya diakhiri front end Anda. Proxy balik HTTP lapis tujuh yang melepas TLS bukan objek yang sama dengan penerus TCP lapis empat, dan penerus UDP juga bukan. Tata letak biasa Access Server pada port 443 membuat daemon OpenVPN TCP mengenali lalu lintas peramban dan menyerahkannya ke layanan web, sehingga menyisipkan terminator HTTPS yang tidak terkait di depan tidak mempertahankan penanganan protokol daemon itu. Berbagi angka 443 tidak membuat dua desain setara.

Kondisi ketiga adalah di mana kegagalan mendarat. Kegagalan sebelum VPN dan kegagalan kanal kendali terlihat mirip pada klien yang hanya mengatakan "menghubungkan", tetapi keduanya meninggalkan bukti di tempat berbeda. Jika format lama yang dipakai, bootstrap adalah kandidat. Jika format baru yang dipakai, log akses web yang kosong memang diharapkan dan tidak membuktikan apa pun ke arah mana pun.

Ketika artefaknya lama: bootstrap gagal lebih dulu

Bacalah galat sebenarnya dari klien, bukan keadaan akhirnya. Bidang yang menarik adalah galat HTTPS, identitas server yang diharapkan klien, tujuan permintaan itu pergi, dan apakah validasi sertifikat selesai. Lalu cocokkan dengan log layanan web dan proxy di sisi server.

Peramban yang mencapai halaman masuk bukan bukti bahwa autentikasi API klien ini berhasil. Itu permintaan berbeda, dengan ekspektasi sertifikat berbeda dan sering kali nama host berbeda. Jika portal dilayani dengan benar dan klien tetap gagal, ketidaksepakatan ada di jalur bootstrap, bukan di kata sandi pengguna.

Jangan buat perbandingan lolos dengan menonaktifkan verifikasi TLS atau melonggarkan kebijakan autentikasi. Itu mengubah ketidakcocokan konfigurasi yang dapat didiagnosis menjadi jalur yang berfungsi tetapi tidak terverifikasi, dan justru perubahan itulah yang mengubah uji sementara menjadi lubang permanen. Dokumentasi profil koneksi Access Server menjelaskan kedua generasi dan alur profil sementara, dan itulah rujukan yang perlu diperiksa sebelum menganggap proxy yang bersalah.

Ketika artefaknya baru: bacalah kanal kendali

Dengan profil bergaya 2.9, klien langsung menuju titik akhir VPN asli. Periksa titik akhir di profil, transport yang dipakai, dan galat kanal kendali. Jika klien tidak pernah mengirim permintaan HTTP, itu konsisten dengan desain dan bukan gejala.

Di sinilah pertanyaan proxy berubah bentuk. Pelepasan HTTPS tidak dapat mematahkan aliran hanya-TCP yang tidak pernah dilihatnya, tetapi masih dapat mematahkan unduhan yang menerbitkan profil, dan penerus hanya-TCP tidak akan membawa UDP sama sekali. Periksa transport mana yang diminta profil sebelum menyimpulkan bahwa front end tidak relevan.

Penerusan TLS untuk satu aliran adalah tata letak sempit. Itu tidak menyediakan penerusan UDP, dan tidak mereproduksi perilaku penerusan layanan daemon itu sendiri pada 443. Jika front end Anda melakukan salah satunya, sebutkan yang mana, karena penanganannya berbeda.

Penanganan yang tetap sempit

Pemeriksaan paling tidak mengganggu adalah membuat profil baru yang didukung untuk akun uji dan terhubung melalui titik akhir asli yang dimaksud dengan persyaratan autentikasi yang sama. Jika itu berhasil dan profil lama yang disimpan tidak, Anda telah memisahkan artefak dari server dan dari proxy dalam satu langkah.

Distribusi profil terkunci pengguna menghapus ketergantungan bootstrap lama sepenuhnya, karena tidak ada pertukaran profil sementara yang bisa gagal. Itu harus diterbitkan untuk pengguna yang dimaksud, tidak pernah disalin dari administrator, dan itu mengubah apa yang berwenang dilakukan klien, jadi perlakukan sebagai keputusan kebijakan, bukan akal-akalan.

Lalu perbaiki tata letak penerbitan agar setiap jalur yang diperlukan ada: jalur web untuk unduhan dan penggunaan portal, serta jalur VPN asli pada transport yang diharapkan profil. Pertahankan pekerjaan proxy pada satu lapisan. Terowongan terkunci pengguna yang berfungsi membuktikan jalur itu bekerja; itu tidak membuktikan setiap tata letak proxy mendukung setiap generasi, dan kegagalan bootstrap lama tidak menghukum format yang lebih baru.

• Identifikasi generasi artefak sebelum menyentuh proxy.
• Tetapkan apakah kegagalan terjadi sebelum terowongan atau di dalamnya.
• Pastikan apa yang diakhiri front end: HTTP, aliran TCP, atau UDP.
• Uji profil yang baru diterbitkan terhadap titik akhir asli dengan kebijakan tidak berubah.