Mengapa menyalin konfigurasi server OpenVPN ke cabang gagal

Menyalin konfigurasi server yang berfungsi, menukar beberapa alamat, lalu menyebutnya profil cabang biasanya menghasilkan koneksi. Itu hasil terburuk, karena cabang kemudian berjalan dengan peran yang salah, memaparkan materi yang tidak seharusnya keluar dari hub, dan meninggalkan asosiasi rute yang tidak diingat siapa pun pernah dibuat. Koneksi itu menyembunyikan tiga masalah sekaligus, dan terowongan sudah naik sebelum ada yang memeriksanya.

Memperlakukan cabang sebagai peer dengan identitas dan peran jaringan sendiri adalah yang membuat profil benar. Perbaikannya bukan salinan yang lebih baik, dan sisa halaman ini membahas apa yang seharusnya dipegang klien.

Dua peran yang tampak seperti satu berkas

Dalam mode TLS kedua pihak punya tugas yang saling melengkapi. Satu sisi mendengarkan, memegang sertifikat dan kunci server, dan memutuskan klien mana yang boleh terhubung. Sisi lain memulai, memverifikasi pendengar, dan menyajikan identitasnya sendiri.

Berkas server memuat direktif yang tidak masuk akal pada klien: alamat ikat dan port untuk mendengarkan, kumpulan alamat untuk dibagikan, dan sering kali daftar dorong untuk pengaturan yang harus diterima klien. Menyalinnya ke cabang menghasilkan perangkat yang berusaha menjadi pendengar sekaligus klien.

Kunci privat adalah bagian yang paling penting. Klien tidak boleh pernah membawa kunci privat server, dan tidak memerlukan kunci penandatanganan CA. Sertifikat CA adalah materi kepercayaan publik; kunci penandatanganan berada di tempat sertifikat diterbitkan.

Apa yang harus dimuat profil cabang

Profil cabang memerlukan titik akhir jarak jauh dan transport, identitas server tepercaya, sertifikat dan kunci cabang itu sendiri, serta rute dan pengaturan DNS yang benar-benar dibutuhkan cabang. Tidak ada lagi yang wajib.

Jaga identitas cabang terpisah per lokasi. Dua cabang berbagi satu sertifikat berarti mencabut yang satu menonaktifkan yang lain, dan log hub tidak dapat membedakannya. Identitas per lokasi adalah yang membuat jejak audit dan kisah pencabutan sama-sama berjalan.

Hati-hati dengan alur kerja peralatan. Paket Client Export pfSense menghasilkan profil untuk konteks Remote Access yang memenuhi syarat, dan daftar servernya hanya memuat server yang dikonfigurasi dalam mode Remote Access. Server situs-ke-situs dari mode lain tidak muncul, dan ketidakhadiran itu adalah informasi, bukan undangan menyalin rahasia server.

Jika peralatan tidak mengekspor profil yang Anda butuhkan, gunakan alur kerja klien situs-ke-situs yang terdokumentasi atau bangun profil dari contoh yang didukung pada rilis terpasang. Ekspor cadangan server ke cabang hanya jika rencananya memulihkan server, yang bukan demikian. Cadangan juga membawa materi privat hub, jadi memindahkannya ke cabang adalah keputusan penanganan kunci, bukan pemindahan berkas. Simpan di hub dan buat identitas klien di tempat sertifikat diterbitkan.

Asosiasi peer-ke-jaringan terpisah

Klien cabang yang berhasil terhubung tetap belum dapat melewatkan lalu lintas untuk LAN-nya sampai hub tahu bahwa peer ini memiliki prefiks itu. Asosiasi itu hidup di hub, terikat pada identitas klien, dan terpisah dari rute cabang sendiri menuju jaringan jarak jauh. Tanpanya, host cabang tampak dapat dijangkau dalam statistik terowongan dan tidak dapat dijangkau dalam praktik. Log hub adalah tempat memastikan apakah asosiasi diterapkan.

Menambahkan rute di sistem operasi hub bukan hal yang sama dengan memberi tahu OpenVPN klien mana yang memiliki prefiks. Tanpa asosiasi per klien, paket mencapai antarmuka terowongan dan dibuang karena tidak ada peer yang mengklaim tujuan.

Di sisi cabang, kebutuhan yang sepadan adalah rute menuju jaringan yang harus dijangkau, ditambah perute LAN yang tahu cara mengembalikan lalu lintas ke cabang. Kepemilikan di sisi server dan rute tujuan di sisi klien adalah objek berbeda, dan terowongan yang berfungsi hanya membuktikan lompatan pertama. Catat keduanya dalam catatan serah terima cabang, karena insinyur berikutnya hanya akan menemukan salah satunya.

Membuktikan bahwa cabang adalah peer yang Anda pikirkan

Verifikasi identitas sebelum memverifikasi lalu lintas. Log hub harus menampilkan nama umum sertifikat cabang, dan alamat yang diterima klien harus cocok dengan kumpulan atau penetapan tetap yang Anda maksudkan. Jika log menampilkan nama lain, profil membawa identitas orang lain.

Lalu verifikasi asosiasi dengan mengirim satu permintaan dari host cabang ke sumber daya di sisi hub dan pastikan berhasil dengan alamat sumber yang diharapkan. Uji tujuan yang tidak boleh dijangkau cabang dan pastikan gagal, karena rute permisif yang kebetulan berfungsi tidak sama dengan kebijakan yang benar.

Terakhir, cabut identitas cabang dan pastikan koneksi gagal sementara sertifikat hub sendiri dan lokasi lain tetap berfungsi. Jika pencabutan merusak hub, peran dan identitas pernah dibagikan di suatu tempat, dan itulah temuan yang layak dibawa kembali ke desain.

Cabang yang selesai adalah cabang dengan identitas terdokumentasi, profil hanya-klien, asosiasi peer-ke-jaringan di hub, dan jalur balik yang teruji. Membalik teks di berkas server tidak memberi Anda satu pun dari itu.