Di mana TLS berada di dalam OpenVPN, dan apa yang mengubah bentuknya

OpenVPN memang memakai TLS, dan orang rutin memperluasnya menjadi klaim yang tidak bisa ia pikul: bahwa tunnel karenanya tampak seperti peramban yang mengunjungi situs. Bagian pertama benar. Bagian kedua tidak. TLS di sini milik kanal kendali yang berjalan di dalam wadah OpenVPN sendiri, bersama kanal muatan dengan kriptografi yang sama sekali berbeda, sehingga siapa pun yang memeriksa byte pembuka melihat OpenVPN.

Dua percakapan dalam satu amplop

Bayangkan sesi sebagai dua percakapan yang berbagi satu amplop. Satu memvalidasi sertifikat dan menurunkan materi kunci. Yang lain mengenkripsi apa yang sebenarnya Anda kirim, memakai hasil yang pertama.

Amplop itu adalah protokolnya. Setiap paket dimulai dengan tajuk kecil yang menyebut jenisnya, dan tajuk itu datang sebelum apa pun yang lain.

Apa yang sebenarnya datang lebih dulu

Karena urutan itu, hal pertama di kabel bukanlah rekaman TLS. Itu tajuk OpenVPN, diikuti isi kanal yang diumumkan tajuk tersebut. Sebuah ClientHello ada di sana, hanya saja bukan di byte nol. Tidak perlu dekripsi untuk menyadari perbedaannya, karena bentuknya sendiri sudah membocorkannya.

Nilai bawaan juga penting di sini. Alirannya UDP ke 1194 kecuali profil memilih TCP. Pada kedua kasus tampilan luarnya adalah tunnel, bukan permintaan web.

Tiga cara jujur untuk mengubah bentuk

Terminator TLS seperti stunnel menerima TLS pada satu port di tiap ujung dan menyerahkan aliran yang sudah didekripsi ke OpenVPN secara lokal, sehingga jaringan melihat TLS ke port itu. Protokol yang merupakan TLS sejak byte pertama berperilaku lain lagi: pertukaran yang kompatibel dengan AnyConnect yang diterapkan ocserv menyerupai akses jarak jauh korporat yang sudah diharapkan banyak jaringan. SSTP, yang hadir bersama Windows, punya sifat yang sama pada produk lain.

Di Linux, opsi -w pada SSH membawa tautan titik-ke-titik di dalam sesi SSH, yang berguna ketika SSH adalah satu-satunya protokol yang diizinkan. Ini yang termurah dari keempatnya jika SSH sudah berfungsi dari jaringan itu, dan paling tidak berguna jika tidak.

Apa yang tidak diubah oleh semuanya

Tidak satu pun dari ini mengubah apa yang bisa dijangkau tunnel. Semuanya tidak membuat alamat yang diblokir menjadi terjangkau, tidak mengautentikasi siapa pun, dan tidak menentukan rute.

Pembungkus juga memakan satu komponen. Dua pendengar dan dua berkas konfigurasi berarti dua tempat kegagalan, dan keduanya tampak identik dari kursi pengguna. Anggarkan itu sebelum mengadopsinya. Sesi tetap menjadi satu aliran terenkripsi berumur panjang ke satu tujuan, dan volumenya serta waktunya tetap terlihat.

Diagnosis dulu, baru pilih

Jadi diagnosislah dulu. UDP yang terbuang dijawab dengan mode TCP, dan tanda tangan yang dikenali dijawab dengan protokol lain atau pembungkus. Memilih alat sebelum tahu blokirnya adalah cara orang berakhir memelihara tiga lapisan yang semuanya gagal karena alasan yang sama.

Jaringan yang hanya mengizinkan port web mempersempit pilihan ke protokol berbasis TLS pada 443. Menerapkan ketiganya sekaligus memberi tumpukan yang tidak bisa di-debug siapa pun, jadi ubah satu hal dan uji ulang aliran yang sama.

Jika tidak satu pun berlaku, jawaban yang tepat adalah jaringan ini tidak akan membawa tunnel untuk Anda. Itu temuan, bukan kegagalan usaha. Memutar lebih banyak opsi tidak membalikkan keputusan kebijakan yang dibuat di tingkat atas.

Satu batas berdiri di depan semua itu. Izin menjalankan tunnel di jaringan orang lain adalah soal kebijakan, diputuskan terpisah dari apakah mekanismenya berfungsi. Fakta-fakta ini menjelaskan apa yang dilihat pengamat, dan tidak memberikan izin.