Biarkan Satu Klien OpenVPN SSH ke Klien Lain Tanpa Membuka Pool

Satu klien perlu menjangkau layanan SSH klien lain, dan sisa pool harus tetap terisolasi seperti sekarang. Sakelar yang menggoda adalah client-to-client, yang menyalakan akses antar-peer untuk semua orang sekaligus dan menyerahkan keputusan kepada OpenVPN alih-alih kernel. Jawaban yang lebih sempit membiarkan sakelar itu mati dan membiarkan routing serta firewall server sendiri membawa tepat satu aliran.

Mekanismenya lebih penting daripada teks aturannya, karena kedua pendekatan menaruh paket di tempat berbeda. Mengetahui mana yang Anda pilih menjelaskan baik aturan yang tampak tidak melakukan apa pun maupun peer yang terhubung tanpanya.

Ke mana client-to-client memindahkan paket

Dengan client-to-client aktif, server meneruskan paket peer secara internal alih-alih mengirimnya kembali keluar melalui perangkat tunnel, sehingga paket tidak pernah mencapai jalur penerusan kernel. Itu nyaman dan juga berarti firewall Anda tidak pernah melihat aliran yang seharusnya dia awasi. Biarkan opsi mati dan server merutekan paket kembali keluar melalui antarmuka yang sama, yang menempatkannya di depan netfilter. Antarmuka sama masuk, antarmuka sama keluar, dan rantai FORWARD yang menentukan.

Pertukarannya jelas: Anda memperoleh satu titik kebijakan dan mengambil alih pekerjaan routing serta penerusan yang tadinya dilakukan jalan pintas untuk Anda. Pekerjaan itu kecil untuk satu aliran dan tumbuh dengan setiap pengecualian yang Anda tambahkan. Hitung pengecualiannya sekarang, karena kumpulan aturan adalah tempat kebijakan antar-peer sebenarnya hidup.

Jalur yang sebenarnya dilalui paket peer

Anggap layanan OpenVPN 2.6 Community di Linux, pemrosesan TUN di ruang pengguna alih-alih DCO, topologi subnet, tun0, dan pool 10.44.0.0/24 dengan klien A di 10.44.0.21 dan klien B di 10.44.0.37. Dengan topologi subnet, alamat dan netmask yang diterima A sudah mencakup pool, jadi A mengirim paket ke perangkat tunnel tanpa perlu rute tambahan yang didorong. Periksa rute efektif di A alih-alih menganggapnya ada.

Di server paket tiba dialamatkan ke B, yang bukan alamat lokal, jadi diteruskan. Penerusan IPv4 harus aktif agar itu terjadi sama sekali, dan pencarian rute harus mengirim paket kembali keluar melalui tun0. Karena itu firewall melihat aliran yang diteruskan dengan antarmuka yang sama di kedua sisi, dan itulah detail yang dilewatkan sebagian besar kumpulan aturan. Tidak ada terjemahan sumber yang diperlukan di sini, dan menjaga alamat A tetap utuh itulah yang memungkinkan B menerapkan aturannya sendiri berbasis sumber.

Dua aturan di server, dalam urutan ini

Tiga aturan membawa seluruh izin: penerusan, pengecualian pasangan, dan penolakan default untuk pasangan tunnel. Aturan penerimaan menyebutkan pasangan dan layanannya, sehingga izin itu bertahan pada pool yang tumbuh. Letakkan sebelum penolakan menyeluruh apa pun untuk lalu lintas tunnel-ke-tunnel, karena kecocokan pertama yang menang:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Perintah-perintah itu bersifat ilustrasi dan termasuk dalam mekanisme apa pun yang dipakai host Anda untuk menyimpan aturan; penyisipan saat runtime hilang pada boot berikutnya. Aturan stateful-lah yang membuat balasan B dan jabat tangan TCP kembali tanpa penerimaan kedua yang dicerminkan.

Periksa penghitungnya setelahnya, bukan daftar aturannya, karena aturan yang tidak pernah cocok terlihat sama persis dengan yang berfungsi. Jika penghitung tetap nol, paket tidak menempuh jalur yang Anda kira.

Apa yang masih harus diizinkan B

B menjalankan layanan SSH, jadi B yang memutuskan apakah ada yang mendengarkan di alamat tunnel dan apakah firewall host-nya sendiri menerima sumbernya. Izin jaringan di server bukan izin untuk akun mana pun di B, dan verifikasi kunci host serta autentikasi pengguna tetap berlaku seperti dari mana pun.

Uji kasus positifnya lebih dulu: koneksi SSH baru dari A ke alamat tunnel B, diterima dengan kunci host yang diharapkan. Lalu uji peer lain atau port lain dan pastikan ditolak, karena izin yang diam-diam mengizinkan segalanya tidak bisa dibedakan dari yang berfungsi sampai hal itu penting. Kedua bagian uji itu perlu, dan yang kedua itulah yang orang lewati.

Catat alamat yang ditetapkan, rute efektif di kedua klien, dan aturan persisnya di server dan di B. Ping yang berhasil ke gateway atau port terbuka di server tidak membuktikan satu pun dari ini, karena keduanya bisa benar sementara penerusan antar-peer masih diblokir. Tulis angka-angka itu saat tunnel menyala, karena alamat yang diterima klien setelah menyambung ulang bisa berbeda.