Dua nama DNS, satu port OpenVPN: apa yang benar-benar memilih

Dua catatan A, satu alamat, satu daemon: nama apa pun yang diketik pengguna, paket yang tiba tetap identik, dan proses yang terikat ke port 1194 tidak punya apa pun untuk membedakan keduanya. Ini bukan salah konfigurasi yang menunggu diperbaiki; ini batas dari apa yang bisa diungkapkan sebuah pencarian nama. Apa pun yang memilih di antara dua instans OpenVPN harus berupa nilai yang dimasukkan klien ke dalam koneksi dan dapat dibaca balik oleh frontend, dan klien OpenVPN standar tidak menaruh nilai semacam itu secara terbuka. Berikut ini adalah ke mana hal itu membawa Anda, dan penataan mana yang benar-benar memisahkan lalu lintas.

Mulailah dari apa yang dikembalikan resolver

Klien meminta vpn-a.example dan menerima sebuah alamat; alamat itu ditambah port adalah seluruh yang ia dial. Nama itu habis secara lokal, selama pencarian, dan tidak pernah menjadi bidang di kabel, sehingga listener di ujung lain tidak dapat melihat label mana yang dipakai. Arahkan vpn-a.example dan vpn-b.example ke satu host dan kedua pencarian menghasilkan tujuan yang sama, itulah sebabnya daemon menyerap kedua koneksi ke dalam satu instans tanpa mencatat perbedaan. Profil berbasis alamat berperilaku persis seperti yang berbasis nama, karena alasan yang sama.

Ini juga menutup sekelompok jalan pintas yang menggoda: alias tambahan, memilih sertifikat per nama pada satu soket, atau aturan firewall yang dikaitkan dengan nama yang ditanyakan. Tidak satu pun darinya dapat bertindak atas informasi yang sudah dibuang sebelum paket pertama meninggalkan klien. Jika dua server harus tetap terpisah, pemisahan itu harus ikut bersama koneksinya sendiri, yakni alamat, port, atau bidang payload yang didefinisikan protokol.

Satu-satunya pemilih yang dihitung berjalan di dalam paket

HTTP menanganinya dengan header Host, dan TLS dengan ekstensi nama server di ClientHello, dan begitulah satu alamat melayani banyak situs di balik satu listener. Keduanya bekerja karena protokol di kabel membawa permintaan untuk layanan tertentu. Fakta relevan tentang OpenVPN adalah tidak satu pun bidang itu hadir pada lapisan yang diperiksa kotak perantara.

Dalam penataan standar, jabat tangan TLS yang melindungi kanal kendali terjadi setelah sesi luar terbentuk dan dibawa di dalamnya, sehingga listener yang belum mengakhiri sesi itu melihat aliran buram. Ia masih bisa mengatakan bahwa ini OpenVPN, karena opcode dan pembingkaian pada bita pembuka dapat dikenali, tetapi nama server, jika ada, berada di bagian terenkripsi. Rancangan yang mengharapkan membaca host virtual dari paket luar sedang membaca bidang yang tidak pernah ditulis protokol di sana. Itu berasal dari cara terowongan dibangun, bukan dari celah yang bisa ditutup pencocokan pola yang lebih cerdas.

Di mana pemisah protokol berhenti

Multiplekser jenis yang didokumentasikan proyek sslh mendengarkan pada satu port, memeriksa bita pembuka, dan menyerahkan koneksi ke backend mana pun yang berbicara protokol yang dikenali. Itu nilai nyata ketika satu port harus melayani SSH, HTTPS, dan OpenVPN sekaligus.

sslh menyimpan probe terpisah untuk setiap protokol, dan probe TLS-nya dapat menarik nama server atau nilai ALPN dari ClientHello yang asli. Mengenali OpenVPN asli adalah klasifikasi yang berbeda dari membaca ekstensi TLS, dan keduanya tidak bertumpuk, karena klien yang tidak pernah mengirim ClientHello ke soket pendengar meninggalkan probe tanpa apa pun untuk dibaca. Karena itu aturan yang cocok dengan OpenVPN menjawab “ini klien OpenVPN” dan tidak melangkah lebih jauh. Dua backend OpenVPN di balik aturan itu tidak dapat dibedakan, frontend tidak punya dasar untuk memilih, dan setiap sesi mendarat di tempat yang sama. Multipleksing berbagi satu port di antara layanan berbeda; ia tidak melakukan hosting virtual di dalam satu layanan.

Penataan yang benar-benar memisahkan dua server

Pemisahan jujur termurah adalah alamat publik kedua, satu per instans, dan profil yang ada sudah membawa yang diperlukan karena menunjuk ke alamat berbeda. Berikutnya adalah port berbeda pada alamat yang sama, yang tidak memakan biaya selain satu angka di setiap profil. TCP dan UDP memelihara tabel port terpisah, sehingga 1194/tcp dan 1194/udp adalah soket yang tidak berhubungan dan satu dari masing-masing dapat hidup berdampingan pada satu host; itu pemisahan transport, bukan perutean berbasis nama, dan sering dikacaukan dengannya. Kedua opsi bertahan dari tinjauan firewall, karena aturannya cocok dengan sesuatu yang benar-benar dikandung paket.

Jika batas yang Anda butuhkan berjalan di antara kelompok pengguna alih-alih antara dua implementasi, satu instans dengan konfigurasi klien berbeda, penanganan sertifikat sendiri, dan kebijakan akses eksplisit dapat menutupinya. Yang dibeli adalah kebijakan di dalam server, bukan isolasi antar server, dan keduanya syarat yang berbeda. Isolasi yang harus bertahan di bawah kompromi tetap membutuhkan alamat atau tepi firewall.

Terminator TLS yang diletakkan di depan OpenVPN dapat mengekspos nama server sungguhan ke frontend yang cakap, tetapi hanya bila sisi klien juga dikonfigurasi untuk lapisan tambahan itu. Profil yang ada tidak memperoleh perilaku itu hanya dengan diarahkan ke alamat yang sama.

Buktikan pemilih sebelum membangun

Namai bidang yang akan mengidentifikasi backend, lalu pastikan klien benar-benar mengirimnya; jika jawabannya alamat, rencana bertahan, dan jika itu nama server di dalam jabat tangan yang tidak pernah mencapai listener, tidak ada pekerjaan DNS yang akan menyelamatkannya. Tiga perintah menyelesaikan sisi pendengar dengan cepat.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

Baris openssl hanya memberikan sertifikat di tempat sesuatu pada alamat itu mengakhiri TLS; terhadap listener OpenVPN asli ia mandek atau gagal, dan itu sendiri jawaban tentang apa yang diekspos lapisan luar. Baris journal, dibaca pada setiap backend, menunjukkan instans mana yang menerima sesi. Log frontend mencatat apa yang diklasifikasikan dan tidak pernah apa yang dimaksudkan, sehingga backend tetap menjadi satu-satunya otoritas tentang di mana pengguna mendarat.

Akhiri dengan dua profil yang dimaksudkan untuk mencapai server berbeda, hubungkan satu per satu, dan catat log backend untuk masing-masing. Jika kedua sesi muncul di journal yang sama, pemilihnya hilang, bukan salah konfigurasi, dan perbaikannya adalah alamat atau port yang dapat dituju klien. Mengedit aturan perutean tidak akan membantu, karena aturan itu tidak pernah diberi apa pun untuk dirutekan. Setelah pemisahan itu nyata, tuliskan di samping profil agar orang berikutnya tidak menambahkan alias kedua dan berharap itu melakukan pekerjaannya.