Mengapa proksi Cloudflare tidak boleh membawa OpenVPN pada satu nama

Satu mesin menjalankan laman web dan pelayan OpenVPN, dan godaannya ialah menghalakan satu nama hos ke arahnya dan membiarkan awan jingga menguruskan trafik. Proksi menguruskan HTTP dan HTTPS. Ia tidak menguruskan sesi OpenVPN, tidak kira port mana sesi itu gunakan. Dua nama, satu langsung dan satu melalui proksi, tidak kos apa-apa dan menghapuskan seluruh kelas kekeliruan ini.

Dua nama, dua pengangkutan

Berikan laman web rekod berproksi supaya trafik HTTP dan HTTPS-nya melalui Cloudflare. Berikan VPN rekod DNS sahaja yang menyelesaikan terus ke pintu masuk VPN awam, dan biarkan klien menggunakan port UDP atau TCP yang dikonfigurasikan untuknya.

Kedua-dua nama boleh berakhir pada mesin asal yang sama. Bezanya ialah apa yang berlaku antara klien dan mesin itu, dan perbezaan itulah inti pemisahan ini.

Rujukan port rangkaian Cloudflare menyenaraikan port yang diterima oleh proksi web biasa. Senarai itu tentang HTTP dan HTTPS pada port tersebut, bukan tentang protokol sewenang-wenangnya yang kebetulan berkongsi satu nombor.

Port bukan protokol

Memindahkan OpenVPN ke TCP 443 tidak menjadikannya HTTPS. Proksi masih mengharapkan permintaan HTTP pada permulaan sambungan, dan klien OpenVPN menghantar mesej kawalan binari sebagai gantinya. Sambungan gagal dengan cara yang kelihatan seperti sekatan rangkaian kerana tiada apa yang berguna sampai ke log.

Jika keperluan itu benar-benar meletakkan produk Cloudflare dalam laluan data VPN, nilai produk yang mendokumenkan sokongan untuk protokol yang anda perlukan. Jangan andaikan awan jingga ialah terowong TCP atau UDP umum, kerana ia ialah proksi songsang untuk trafik web dengan tugas tertentu.

Rekod DNS sahaja ialah jawapan membosankan yang berkesan, dan itulah yang patut dituju dahulu.

Satu mesin masih perlukan dua pendengar

Nama berasingan tidak membenarkan dua proses mengikat alamat, port dan pengangkutan yang sama pada masa yang sama. Jika pelayan web sudah memegang TCP 443 pada semua alamat, instans OpenVPN tidak boleh mengambilnya juga tanpa aturan yang disengajakan.

Ikat pendengar VPN pada port lain, atau pada alamat lain, atau letakkan multiplekser berdokumen di hadapannya dan terima kos operasi yang menyertainya. Setiap pilihan itu patut kelihatan dalam peraturan firewall, kerana pendengar yang tiada siapa mendokumenkannya ialah yang terlepas semasa insiden. Tulis ikatan yang dipilih dalam runbook yang sama yang menerangkan terowong itu. Dengan itu orang seterusnya tidak akan menemukannya semula pada pukul dua pagi.

Sijil mengikut sambungan yang dilindunginya

Sambungan TLS pelayar ke Cloudflare dan sambungan Cloudflare ke asal anda ialah dua hubungan berasingan dengan dua sijil berasingan. Pelayar melihat sijil tepi. Asal membentangkan sijilnya sendiri kepada Cloudflare, dan sijil Cloudflare Origin CA memang ditujukan untuk hubungan kedua itu.

Sijil asal itu dipercayai oleh Cloudflare dalam mod Full (strict) dan ia bukan sijil pelayar yang dipercayai secara umum. Jika seseorang melawat nama hos DNS sahaja secara langsung dan menerima amaran, itu akibat yang dijangka daripada laluan kepercayaan yang berubah, bukan bukti bahawa penyulitan berhenti.

Oleh itu laman web yang dilawati secara langsung memerlukan rantaian sijil yang dipercayai oleh pelayarnya. Itu boleh wujud bersama laman berproksi yang asalnya sama sekali tidak bertujuan untuk dilawati.

OpenVPN membawa identiti pelayan dan pengesahan kliennya sendiri, dengan pihak berkuasa sijilnya sendiri dan perlindungan saluran kawalannya sendiri. Gembok pada laman web tidak menyediakan apa-apa daripada itu, dan kedua-dua proses penyediaan patut kekal berasingan.

Pendedahan mengikut nama

Rekod VPN DNS sahaja menerbitkan alamat yang ditunjuknya. Jika alamat itu juga asal web, asal itu tidak tersembunyi, dan menyebutnya tersembunyi kerana nama lain berproksi ialah kesilapan yang kekal sehingga seseorang mengimbasnya.

Tentukan permintaan web mana yang boleh mencapai asal secara langsung dan laksanakan di asal, kemudian benarkan pendengar VPN mengikut syaratnya sendiri. Halaman pengurusan, muat turun profil dan pendengar data boleh mempunyai tiga keperluan pendedahan berbeza walaupun satu pakej menyediakan ketiga-tiganya.

Kekalkan pautan yang dijana pada nama web awam dan skema HTTPS, dan kekalkan profil klien pada nama VPN dengan protokol dan port sebenar. Kedua-dua perkhidmatan tidak sepatutnya bergantung pada menukar tetapan proksi satu sama lain semasa operasi biasa.

Urutan kerja: nama berproksi untuk laman, nama DNS sahaja untuk VPN, pendengar berasingan, sijil bagi setiap hubungan, kemudian satu ujian yang membuktikan setiap nama hanya mencapai perkhidmatan yang sepatutnya.