Bisakah klien di dua server OpenVPN saling menjangkau?

Menyiapkan OpenVPN server kedua memberi Anda tempat kedua bagi klien untuk terhubung, dan tidak lebih. Itu tidak menempatkan klien tersebut di jaringan server pertama, dan opsi bernama client-to-client hanya mengubah penerusan di dalam satu proses server. Kedua kumpulan menjadi satu jaringan ketika Anda merutekan di antara keduanya dengan sengaja, dengan satu pemilik untuk setiap arah. Semua di bawah ini mengasumsikan mode TUN di ruang pengguna dengan penerusan internal itu dimatikan, sehingga kernel yang mengambil keputusan.

Mitos: satu daftar akun, satu jaringan

Autentikasi dan keterjangkauan dicampuradukkan karena keduanya berada di konfigurasi server. Pengguna yang dapat masuk ke salah satu dari dua gateway, dari luar tampak seperti pengguna pada satu sistem dengan dua pintu. Di dalam, setiap server membagikan alamat dari kumpulannya sendiri dan memasang rute hanya untuk klien yang diakhirinya. Jadi klien di gateway A yang mengirim paket ke klien di gateway B meminta tujuan yang belum pernah didengar server-nya sendiri. Paket menuju rute default A, meninggalkan terowongan, dan tiba di firewall yang tidak pernah diminta mengizinkannya.

Menambahkan server kedua karena itu tidak menambah redundansi, penemuan, atau domain siaran bersama. Itu menambah jaringan terutekan yang membutuhkan rencana, dan rencana dimulai dari pengalamatan.

Beri setiap gateway kumpulan dan alamat transitnya sendiri

Dua rentang yang tidak boleh tumpang tindih dengan apa pun, ditambah tautan transit kecil antar host, adalah seluruh rencana alamat. Jaga transit pada segmen privat yang Anda kendalikan, dan tuliskan angkanya sebelum server mana pun memberikan sewa.

Lawan godaan memberi kedua server kumpulan yang sama agar profil tetap identik. Rute kernel tidak dapat menyatakan host mana dari dua host yang saat ini memiliki alamat sembarang di dalam rentang bersama, jadi tabel perutean akan menunjuk ke satu gateway dan klien mungkin terpasang pada yang lain. Nama antarmuka adalah konvensi lokal, bukan keadaan bersama. Kedua host di sini menyebut perangkat terowongan tun0 dan tautan transit transit0, yang tidak masalah karena tidak ada paket yang membawa nama itu.

Pasang rute di kedua sisi

Setiap gateway memerlukan rute ke kumpulan yang lain melalui alamat transit, dan penerusan harus aktif agar salah satunya dapat bertindak sebagai hop. Konfirmasikan tabel saat ini dulu, lalu tambahkan entri dan buat persisten melalui manajer jaringan host, bukan kait penyambungan ulang.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Cerminkan itu di host lain dengan kumpulan ditukar. Menambahkan rute yang sama berulang kali dari skrip yang tidak terkait adalah cara host berakhir dengan beberapa salinan dan perubahan misterius saat seseorang membaca tabel berikutnya. Jika tautan transit itu sendiri adalah terowongan, rute menunjuk ke topologi terowongan itu dan hop harus bertahan dari penyambungan ulangnya. Alamat transit yang hilang selama tiga puluh detik membawa serta jalur antar kumpulan, yang merupakan sifat desain yang layak dinyatakan daripada ditemukan.

Dorong rute klien tanpa memalsukan kepemilikan

Klien memerlukan rute ke kumpulan jarak jauh, jika tidak sistem operasi mereka sendiri mengirim paket ke gateway defaultnya dan terowongan tidak pernah melihatnya. Konfigurasi server adalah tempat alami untuk mengirimkannya.

push "route 10.64.20.0 255.255.255.0"

Letakkan baris cermin di konfigurasi server lain, lalu sambungkan ulang klien uji dan baca tabelnya. Klien yang mengabaikan rute yang didorong memerlukan konfigurasi terverifikasinya sendiri, dan rute yang tidak pernah tiba bukanlah kontrol akses. Jangan beri klien iroute untuk seluruh kumpulan gateway lain. Direktif itu ada untuk subnet di belakang satu klien yang terhubung, dan menggunakannya untuk menutupi rute antar gateway yang hilang menghasilkan server yang percaya bahwa ia memiliki alamat yang tidak dapat dijangkau.

Buktikan satu permintaan dan tolak yang lain

Pilih operasi nyata, misalnya HTTPS dari klien di 10.64.10.21 ke layanan di 10.64.20.37, dan izinkan tepat itu di kedua host. Setiap firewall menerima permintaan di sisi masuknya dan balasan yang dilacak di sisi kembali; kebijakan layanan tujuan sendiri tetap harus menerimanya.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Dengan rute timbal balik, NAT sumber tidak diperlukan dan di sini secara aktif merugikan: menerjemahkan sumber menyembunyikan klien mana yang membuat permintaan dan mengalahkan kebijakan berbasis sumber di sisi tujuan. Periksa apakah aturan masquerade yang ada untuk keluar internet juga tidak menangkap jalur ini. Lalu uji penolakannya. Layanan yang harus tetap lokal di kumpulan B harus tetap tidak terjangkau dari kumpulan A, dan pasangan klien di gateway yang sama juga perlu diuji, karena kebijakan penerusan yang baru Anda ubah juga berlaku bagi mereka.

Satu koreksi lagi pada model mental: tautan transit membawa paket dalam yang sudah didekripsi, jadi itu batas kepercayaan, bukan jaminan privat. Jika melintasi jaringan yang tidak Anda kendalikan, lindungi hop itu dengan terowongan terenkripsi yang disetujui dan rutekan melalui topologi aslinya. TLS ujung ke ujung tetap mengautentikasi aplikasi sendiri, itulah sebabnya layanan di dalamnya harus terus memakainya.