Bolehkah klien pada dua pelayan OpenVPN saling mencapai satu sama lain?

Mendirikan pelayan OpenVPN kedua memberi anda tempat kedua untuk klien menyambung, dan tidak lebih. Ia tidak meletakkan klien itu pada rangkaian pelayan pertama, dan pilihan bernama client-to-client hanya mengubah penghantaran dalam satu proses pelayan. Kedua-dua kumpulan menjadi satu rangkaian apabila anda membuat laluan antaranya secara sengaja, dengan pemilik bagi setiap arah. Semua di bawah menganggap mod TUN ruang pengguna dengan penghantaran dalaman itu dimatikan, jadi kernel yang membuat keputusan.

Mitos: satu senarai akaun, satu rangkaian

Pengesahan dan kebolehcapaian dikelirukan kerana kedua-duanya berada dalam konfigurasi pelayan. Pengguna yang boleh log masuk ke mana-mana satu gerbang kelihatan, dari luar, seperti pengguna pada satu sistem dengan dua pintu. Di dalam, setiap pelayan memberikan alamat daripada kumpulannya sendiri dan memasang laluan hanya untuk klien yang ditamatkannya. Jadi klien pada gerbang A yang menghantar paket kepada klien pada gerbang B meminta destinasi yang tidak pernah didengar oleh pelayannya sendiri. Paket itu pergi ke laluan lalai A, meninggalkan terowong, dan tiba di tembok api yang tidak pernah diminta membenarkannya.

Menambah pelayan kedua oleh itu tidak menambah redundansi, penemuan atau domain siaran dikongsi. Ia menambah rangkaian berpenghalaan yang memerlukan pelan, dan pelan itu bermula dengan pengalamatan.

Beri setiap gerbang kumpulan dan alamat transit sendiri

Dua julat yang tidak boleh bertindih dengan apa-apa lagi, ditambah pautan transit kecil antara hos, ialah keseluruhan pelan alamat. Kekalkan transit pada segmen persendirian yang anda kawal, dan tulis nombor itu sebelum mana-mana pelayan mengeluarkan pajakan.

Lawan godaan untuk memberi kedua-dua pelayan kumpulan yang sama supaya profil kekal sama. Laluan kernel tidak boleh menyatakan hos mana antara dua yang kini memiliki alamat sewenang-wenang dalam julat dikongsi, jadi jadual penghalaan akan menunjuk ke satu gerbang dan klien mungkin terpasang pada yang lain. Nama antara muka ialah konvensyen setempat, bukan keadaan dikongsi. Kedua-dua hos di sini memanggil peranti terowong tun0 dan pautan transit transit0, yang tidak mengapa kerana tiada paket membawa nama itu.

Pasang laluan pada kedua-dua belah

Setiap gerbang memerlukan laluan untuk kumpulan yang lain melalui alamat transit, dan penghantaran mesti dihidupkan supaya mana-mana satu boleh bertindak sebagai hop. Sahkan jadual semasa dahulu, kemudian tambah entri dan kekalkannya melalui pengurus rangkaian hos dan bukan cangkuk sambung semula.

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 pada hos lain dengan kumpulan ditukar. Menambah laluan yang sama berulang kali daripada skrip yang tidak berkaitan ialah cara hos berakhir dengan beberapa salinan dan perubahan misteri lain kali seseorang membaca jadual. Jika pautan transit itu sendiri terowong, laluan menunjuk ke topologi terowong itu dan hop mesti bertahan selepas sambung semula. Alamat transit yang hilang selama tiga puluh saat membawa laluan antara kumpulan bersamanya, iaitu sifat reka bentuk yang wajar dinyatakan daripada ditemui.

Tolak laluan klien tanpa memalsukan pemilikan

Klien memerlukan laluan untuk kumpulan jauh, jika tidak sistem pengendalian mereka sendiri menghantar paket ke gerbang lalai dan terowong tidak pernah melihatnya. Konfigurasi pelayan ialah tempat semula jadi untuk menyampaikannya.

push "route 10.64.20.0 255.255.255.0"

Letakkan baris cermin dalam konfigurasi pelayan lain, kemudian sambung semula klien ujian dan baca jadualnya. Klien yang mengabaikan laluan yang ditolak memerlukan konfigurasi yang diluluskan sendiri, dan laluan yang tidak pernah tiba bukan kawalan akses. Jangan beri klien iroute untuk seluruh kumpulan gerbang lain. Arahan itu wujud untuk subnet di belakang satu klien bersambung, dan menggunakannya untuk menutup laluan antara gerbang yang hilang menghasilkan pelayan yang percaya ia memiliki alamat yang tidak dapat dicapainya.

Buktikan satu permintaan dan tolak yang lain

Pilih operasi sebenar, contohnya HTTPS daripada klien di 10.64.10.21 ke perkhidmatan di 10.64.20.37, dan benarkan tepat itu pada kedua-dua hos. Setiap tembok api menerima permintaan pada sisi masuknya dan balasan yang dijejaki pada sisi pulangan; dasar perkhidmatan destinasi sendiri masih perlu 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 laluan timbal balik, NAT sumber tidak perlu dan secara aktif memudaratkan di sini: menterjemah sumber menyembunyikan klien mana yang membuat permintaan dan menggagalkan dasar berasaskan sumber di sisi destinasi. Semak bahawa peraturan masquerade sedia ada untuk keluar internet tidak juga menangkap laluan ini. Kemudian uji penolakan. Perkhidmatan yang sepatutnya kekal setempat pada kumpulan B mesti kekal tidak dapat dicapai dari kumpulan A, dan pasangan klien gerbang sama juga perlu diuji, kerana dasar penghantaran yang baru anda ubah turut terpakai kepada mereka.

Satu lagi pembetulan pada model mental: pautan transit membawa paket dalaman yang dinyahsulit, jadi ia sempadan kepercayaan dan bukan jaminan persendirian. Jika ia merentasi rangkaian yang anda tidak kawal, lindungi hop itu dengan terowong tersulit yang diluluskan dan laluan melalui topologi sebenar. TLS hujung ke hujung masih mengesahkan aplikasi dengan sendirinya, sebab itu perkhidmatan dalaman wajar terus menggunakannya.