Satu Pi, Dua Instance OpenVPN: Apa yang Dibaca Tiap Unit
Dua daemon OpenVPN pada satu Pi membaca berkas konfigurasi berbeda dan keluar melalui hook yang berbeda. Petakan tiap instance, lalu uji jalur payload secara terpisah.
Hitung proses OpenVPN sebelum Anda menyentuh profil. Pi yang menerima pengguna roaming sekaligus menghubungi layanan upstream menjalankan dua daemon, dan masing-masing membaca berkas konfigurasi yang dipilih oleh nama instance yang Anda ketik. Templat bawaan paket kemudian memberi setiap daemon direktori kerja sendiri, berkas status runtime sendiri, dan perangkat tunnel sendiri. Kalau pembagian itu keliru, Anda akan menghabiskan satu malam mengubah pengaturan yang benar di dalam berkas yang tidak pernah dibuka oleh proses yang berjalan.
Setiap Nama Instance Memilih Berkasnya Sendiri
Dalam berkas unit yang dikirim bersama OpenVPN 2.6, argumen start membawa placeholder instance yang diisi dari teks setelah tanda @. Templat server berjalan dari direktori konfigurasi server dan menyelesaikan argumennya terhadap %i.conf di sana, sedangkan templat klien melakukan hal yang sama dari direktori klien. Jadi [email protected] membaca admits.conf di direktori server dan [email protected] membaca uplink.conf di direktori klien, dan tidak satu pun nama itu bermakna di direktori lainnya.
Pastikan pemetaan itu di mesin, jangan menganggap paketnya mempertahankan bawaan upstream. Drop-in dari distribusi boleh mengganti direktori kerja atau argumen konfigurasi sepenuhnya.
systemctl cat [email protected]
systemctl cat [email protected]Baca baris WorkingDirectory dan argumen konfigurasi pada keluaran itu, karena unit yang diaktifkan adalah satu-satunya yang menentukan berkas mana yang dimuat. Drop-in yang menambahkan --config ke ExecStart menang atas templat meskipun jalur templat terlihat benar. Mintalah jalur fragmen dan drop-in kalau Anda ingin tahu apakah ada penimpaan lokal. Kalau kedua peran mengarah ke satu berkas, Anda punya satu proses yang mencoba menjadi server sekaligus klien, dan opsi yang lebih belakang di berkas itu diam-diam menang.
Transport Lokal dan Payload yang Diteruskan Menemui Hook Berbeda
Koneksi terenkripsi server ke setiap pengguna roaming dibuat di Pi itu sendiri, jadi balasan luarnya keluar melalui hook output lokal. Koneksi klien ke peer upstream juga merupakan output yang dibuat secara lokal, meskipun tujuannya jaringan jauh. Payload yang diteruskan adalah kategori ketiga, dan kernel mencocokkannya hanya setelah ia memilih perangkat keluar untuk paket tersebut.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Aturan yang mencocokkan antarmuka keluar di dalam rantai forward dapat mengizinkan atau menjatuhkan paket yang sudah ditetapkan routing ke antarmuka itu, tetapi aturan itu tidak pernah memilih antarmukanya. Ketika satu host mengakhiri satu tunnel dan memulai tunnel lain, kebijakan yang mengirim payload pengguna ke tunnel upstream dan kebijakan yang melindungi balasan terenkripsi Pi sendiri adalah dua keputusan terpisah. Keduanya kebetulan mendarat di NIC fisik yang sama, itulah sebabnya keduanya sering tertukar.
Perbedaan itu menjelaskan kegagalan separuh yang umum. Pengguna terhubung, handshake selesai, dan trafik mereka tetap keluar lewat jalur yang salah, karena handshake tadi lokal sedangkan payload-nya forward dan hanya satu dari keduanya yang pernah diuji.
Rute yang Diimpor Dapat Menelan Balasan ke Pengguna Anda
Pengaturan keamanan profil klien menentukan apa yang boleh didorong upstream ke tabel routing Pi, dan pengalihan yang luas adalah opsi yang mengubah host dual-role yang berfungsi menjadi rusak. Jika rute yang didorong mencakup alamat publik pengguna roaming, balasan yang dibuat server untuk mereka dapat mengikuti rute baru itu masuk ke tunnel upstream, bukan keluar lewat underlay. Orang sering memastikan tunnel ke penyedia masih berfungsi lalu berhenti di situ, karena trafik itu adalah transport tunnel itu sendiri dan tetap mengalir sementara hal lain berperilaku salah.
Kebijakan berbasis sumber atau mark adalah cara kedua aliran tetap terpisah. Opsi mark Linux dari OpenVPN membubuhkan tanda firewall pada paket terenkripsi milik daemon, yang lalu bisa dikirim oleh aturan routing ke tabel khusus. Alamat sumber juga sama ampuhnya ketika balasan luar server selalu keluar dari satu alamat underlay. Pendekatan mana pun memerlukan rute yang sah di tabel yang dipilihnya dan pengecualian untuk endpoint penyedia, kalau tidak tunnel-nya sendiri berhenti muncul.
Tanyakan kepada kernel jalur yang sebenarnya akan ditempuh sebuah balasan sebelum menulis aturan apa pun. Alamat di bawah ini adalah placeholder untuk alamat underlay Pi dan alamat publik satu pengguna roaming.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Verifikasi Pemisahannya, Lalu Hentikan Satu Peran Sekaligus
Uji tiga aliran secara terpisah, karena handshake yang berhasil tidak membuktikan apa pun tentang dua aliran lainnya. Terima koneksi masuk baru, kirim satu aplikasi yang diizinkan melalui pintu keluar upstream, dan pastikan kedua proses masih menjangkau peer masing-masing.
Lalu hentikan peran klien dan perhatikan apa yang tetap dipegang peran server. Ini cara termurah menemukan aturan rute atau mark yang dimaksudkan untuk satu instance tetapi diterapkan pada keduanya.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerYang ingin Anda lihat adalah listener tetap terikat, perangkat tunnel tetap ada, dan log bebas dari galat baru saat peran klien mati. Jika menghentikan klien juga memutus balasan server ke pengguna yang sudah ada, kedua peran berbagi sesuatu yang seharusnya dibatasi untuk salah satunya. Catat instance mana, berkas konfigurasi mana, dan pemilik aliran mana yang disentuh setiap perubahan, karena orang berikutnya yang men-debug host ini kalau tidak akan mengulang penemuan yang sama dari nol.