Mengapa proxy Cloudflare tidak dapat membawa OpenVPN pada satu nama

Satu mesin menjalankan situs web dan server OpenVPN, dan godaannya adalah mengarahkan satu nama host ke mesin itu dan membiarkan awan oranye mengurus lalu lintasnya. Proxy mengurus HTTP dan HTTPS. Proxy tidak mengurus sesi OpenVPN, apa pun port yang dipakai sesi itu. Dua nama, satu langsung dan satu melalui proxy, tidak memakan biaya dan menghapus seluruh jenis kebingungan ini.

Dua nama, dua transport

Beri situs web catatan yang diproksikan agar lalu lintas HTTP dan HTTPS-nya melewati Cloudflare. Beri VPN catatan khusus DNS yang mengarah langsung ke pintu masuk VPN publik, dan biarkan klien memakai port UDP atau TCP yang menjadi konfigurasinya.

Kedua nama bisa berakhir di mesin asal yang sama. Bedanya adalah apa yang terjadi antara klien dan mesin itu, dan perbedaan itulah inti pemisahannya.

Referensi port jaringan Cloudflare mencantumkan port mana yang diterima proxy web biasa. Daftar itu tentang HTTP dan HTTPS pada port tersebut, bukan tentang protokol sembarangan yang kebetulan berbagi satu nomor.

Port bukanlah protokol

Memindahkan OpenVPN ke TCP 443 tidak mengubahnya menjadi HTTPS. Proxy tetap mengharapkan permintaan HTTP di awal koneksi, sedangkan klien OpenVPN justru mengirim pesan kendali biner. Koneksi gagal dengan cara yang tampak seperti pemblokiran jaringan karena tidak ada hal berguna yang sampai ke log.

Jika persyaratannya memang menempatkan produk Cloudflare di jalur data VPN, nilai produk yang mendokumentasikan dukungan protokol yang Anda butuhkan. Jangan menganggap awan oranye adalah terowongan TCP atau UDP umum, karena ia adalah proxy balik untuk lalu lintas web dengan tugas tertentu.

Catatan khusus DNS adalah jawaban membosankan yang berhasil, dan itulah yang harus dituju lebih dulu.

Satu mesin tetap butuh dua pendengar

Nama yang terpisah tidak memungkinkan dua proses mengikat alamat, port, dan transport yang sama pada waktu yang sama. Jika server web sudah memegang TCP 443 di semua alamat, instans OpenVPN tidak bisa mengambilnya juga tanpa pengaturan yang disengaja.

Ikat pendengar VPN ke port lain, atau ke alamat lain, atau pasang multiplekser terdokumentasi di depannya dan terima biaya operasional yang menyertainya. Setiap pilihan itu harus terlihat di aturan firewall, karena pendengar yang tidak didokumentasikan siapa pun adalah yang terlewat saat insiden. Tulis pengikatan yang dipilih ke runbook yang sama yang menjelaskan terowongan. Dengan begitu orang berikutnya tidak menemukannya lagi pukul dua pagi.

Sertifikat mengikuti koneksi yang dilindunginya

Koneksi TLS peramban ke Cloudflare dan koneksi Cloudflare ke asal Anda adalah dua hubungan terpisah dengan dua sertifikat terpisah. Peramban melihat sertifikat tepi. Asal menyajikan sertifikatnya sendiri ke Cloudflare, dan sertifikat Cloudflare Origin CA memang ditujukan untuk hubungan kedua itu.

Sertifikat asal itu dipercaya Cloudflare dalam mode Full (strict) dan bukan sertifikat peramban yang dipercaya secara umum. Jika seseorang mengunjungi nama host khusus DNS secara langsung dan mendapat peringatan, itu konsekuensi yang diharapkan dari jalur kepercayaan yang berubah, bukan bukti bahwa enkripsi berhenti.

Karena itu situs web yang dikunjungi langsung membutuhkan rantai sertifikat yang dipercaya perambannya. Hal itu bisa hidup berdampingan dengan situs yang diproksikan yang asalnya sama sekali tidak dimaksudkan untuk dikunjungi.

OpenVPN membawa identitas servernya sendiri dan autentikasi kliennya, dengan otoritas sertifikatnya sendiri dan perlindungan kanal kendalinya sendiri. Gembok di situs web tidak menyediakan satu pun dari itu, dan kedua proses penyediaannya harus tetap terpisah.

Paparan mengikuti nama

Catatan VPN khusus DNS menerbitkan alamat yang ditunjuknya. Jika alamat itu juga asal web, asalnya tidak tersembunyi, dan menyebutnya tersembunyi karena nama lain diproksikan adalah kesalahan yang bertahan sampai seseorang memindainya.

Putuskan permintaan web mana yang boleh mencapai asal secara langsung dan tegakkan di asal, lalu izinkan pendengar VPN menurut ketentuannya sendiri. Halaman manajemen, unduhan profil, dan pendengar data dapat memiliki tiga persyaratan paparan berbeda bahkan ketika satu paket menyediakan ketiganya.

Pertahankan tautan yang dihasilkan pada nama web publik dan skema HTTPS, serta profil klien pada nama VPN dengan protokol dan port yang sebenarnya. Tak satu pun dari kedua layanan itu boleh bergantung pada pembalikan pengaturan proxy yang lain selama operasi normal.

Urutan pekerjaan: nama yang diproksikan untuk situs, nama khusus DNS untuk VPN, pendengar yang berbeda, sertifikat per hubungan, lalu satu uji yang membuktikan setiap nama hanya mencapai layanan yang seharusnya.