Profil berkunci pelayan gagal di belakang proksi TLS: generasi yang mana?

Seorang pengguna boleh menyambung dan seorang lagi tidak, melalui portal yang sama, pada hari yang sama. Kedua-duanya mempunyai profil berkunci pelayan, kedua-duanya pada binaan Access Server yang sama, dan satu-satunya perbezaan ialah bila profil mereka dijana. Itulah corak yang wajar dikenali, kerana "berkunci pelayan" menamakan dasar dan bukan urutan sambungan. Access Server telah mengeluarkan dua generasi artifak itu, dan proksi songsang TLS hanya berdiri di hadapan salah satu laluannya. Tiga syarat menentukan cabang mana anda berada.

Dua generasi, dua urutan sambungan

Dalam reka bentuk lama, yang berkuat kuasa sehingga 2.8, fail yang diimport ialah pseudo-profil. OpenVPN Connect menggunakannya untuk mengesahkan diri dengan API web Access Server melalui HTTPS, menerima profil sementara berkunci pengguna dan token sesi, dan hanya selepas itu membina VPN. Dua pengangkutan berjalan berturutan, dan yang pertama ialah permintaan web biasa.

Format yang diperkenalkan dengan 2.9 tidak melakukan bootstrap setiap sambungan itu. Ia ialah profil asli yang boleh digunakan oleh OpenVPN klien yang serasi, bukan hanya OpenVPN Connect. Memuat turunnya atau mengimportnya melalui URL masih boleh melibatkan HTTPS — itu langkah penerbitan, bukan pengambilan profil sementara bagi setiap sambungan.

Peningkatan tidak semestinya menulis semula profil yang telah dikeluarkan, jadi versi pelayan semasa masih boleh mengagihkan artifak lama. Binaan pelayan memberitahu anda apa yang mungkin, bukan apa yang diimport oleh pengguna ini.

Tiga syarat yang memilih cabang anda

Syarat pertama ialah generasi artifak. Minta fail itu, lihat bagaimana ia dihasilkan, dan catat versi klien yang mengimportnya. Jika anda tidak dapat menetapkan generasi daripada fail, profil baharu yang dikeluarkan untuk akaun ujian akan memberitahu anda apa yang dihasilkan pelayan hari ini, dan itu maklumat yang berbeza daripada yang dipegang oleh pengguna yang gagal.

Syarat kedua ialah apa yang sebenarnya ditamatkan oleh bahagian hadapan anda. Proksi songsang HTTP lapisan tujuh yang memunggah TLS bukan objek yang sama dengan pemaju TCP lapisan empat, dan pemaju UDP juga bukan. Susunan biasa Access Server pada port 443 menyebabkan daemon OpenVPN TCP mengenali trafik pelayar dan menyerahkannya kepada perkhidmatan web, jadi memasukkan penamat HTTPS yang tidak berkaitan di hadapan tidak mengekalkan pengendalian protokol daemon itu. Berkongsi nombor 443 tidak menjadikan dua reka bentuk setara.

Syarat ketiga ialah di mana kegagalan mendarat. Kegagalan sebelum VPN dan kegagalan saluran kawalan kelihatan serupa dalam klien yang hanya berkata "menyambung", tetapi ia meninggalkan bukti di tempat berbeza. Jika format lama digunakan, bootstrap ialah calon. Jika format baharu digunakan, log akses web yang kosong memang dijangka dan tidak membuktikan apa-apa ke mana-mana arah.

Apabila artifak itu lama: bootstrap gagal dahulu

Baca ralat sebenar klien dan bukan keadaan akhirnya. Medan yang menarik ialah ralat HTTPS, identiti pelayan yang dijangka oleh klien, destinasi permintaan itu pergi, dan sama ada pengesahan sijil selesai. Kemudian padankan dengan log perkhidmatan web dan proksi di sebelah pelayan.

Pelayar yang sampai ke halaman log masuk bukan bukti bahawa pengesahan API klien ini berjaya. Ia permintaan berbeza, dengan jangkaan sijil berbeza dan selalunya nama hos berbeza. Jika portal disajikan dengan betul dan klien masih gagal, percanggahan itu di laluan bootstrap, bukan pada kata laluan pengguna.

Jangan jadikan perbandingan itu lulus dengan mematikan pengesahan TLS atau melonggarkan dasar pengesahan. Itu mengubah ketidakpadanan konfigurasi yang boleh didiagnosis menjadi laluan yang berfungsi tetapi tidak disahkan, dan perubahan itulah yang menjadikan ujian sementara sebagai lubang kekal. Dokumentasi profil sambungan Access Server menerangkan kedua-dua generasi dan aliran profil sementara, dan ia rujukan yang perlu diperiksa sebelum menganggap proksi bersalah.

Apabila artifak itu baharu: baca saluran kawalan

Dengan profil gaya 2.9, klien terus menuju ke titik akhir VPN asli. Siasat titik akhir dalam profil, pengangkutan yang digunakan, dan ralat saluran kawalan. Jika klien tidak pernah mengeluarkan permintaan HTTP, itu konsisten dengan reka bentuk dan bukan gejala.

Di sinilah soalan proksi juga berubah bentuk. Pemunggahan HTTPS tidak boleh memecahkan aliran hanya-TCP yang tidak pernah dilihatnya, tetapi ia masih boleh memecahkan muat turun yang menerbitkan profil, dan pemaju hanya-TCP tidak akan membawa UDP langsung. Periksa pengangkutan mana yang diminta oleh profil sebelum membuat kesimpulan bahawa bahagian hadapan tidak relevan.

Laluan TLS untuk satu aliran ialah susunan sempit. Ia tidak menyediakan pemajuan UDP, dan tidak menghasilkan semula tingkah laku pemajuan perkhidmatan daemon itu sendiri pada 443. Jika bahagian hadapan anda melakukan salah satu daripadanya, nyatakan yang mana, kerana penyelesaiannya berbeza.

Penyelesaian yang kekal sempit

Pemeriksaan paling tidak intrusif ialah menjana profil baharu yang disokong untuk akaun ujian dan menyambung melalui titik akhir asli yang dimaksudkan dengan keperluan pengesahan yang sama. Jika itu berjaya dan profil lama yang disimpan tidak, anda telah memisahkan artifak daripada pelayan dan daripada proksi dalam satu langkah.

Pengagihan profil berkunci pengguna menghapuskan kebergantungan bootstrap lama sepenuhnya, kerana tiada pertukaran profil sementara yang boleh gagal. Ia mesti dikeluarkan untuk pengguna yang dimaksudkan, tidak pernah disalin daripada pentadbir, dan ia mengubah apa yang klien dibenarkan lakukan, jadi anggaplah ia keputusan dasar dan bukan jalan pintas.

Kemudian betulkan susun atur penerbitan supaya setiap laluan yang diperlukan wujud: laluan web untuk muat turun dan penggunaan portal, dan laluan VPN asli pada pengangkutan yang dijangka oleh profil. Kekalkan kerja proksi pada satu lapisan. Terowong berkunci pengguna yang berfungsi membuktikan laluan itu berfungsi; ia tidak membuktikan setiap susunan proksi menyokong setiap generasi, dan kegagalan bootstrap lama tidak menghukum format yang lebih baharu.

• Kenal pasti generasi artifak sebelum menyentuh proksi.
• Tetapkan sama ada kegagalan berlaku sebelum terowong atau di dalamnya.
• Sahkan apa yang ditamatkan oleh bahagian hadapan: HTTP, aliran TCP, atau UDP.
• Uji profil yang baru dikeluarkan terhadap titik akhir asli dengan dasar tidak berubah.