tun yang dibuat sebelumnya di OpenVPN: membandingkan dua model kepemilikan

Seseorang membuat tun1 sebelumnya, profil menyebut dev tun1, dan koneksi tetap tidak terpasang. Keberadaan nama di host hampir tidak menjelaskan apa pun, karena pemasangan bergantung pada ruang nama, jenis perangkat, siapa yang memiliki tautan, dan apa yang diizinkan dilakukan daemon. Menggunakan ulang perangkat juga memaksa keputusan yang disembunyikan konfigurasi bawaan: komponen mana yang menulis alamat dan rute. Mode kegagalan kedua pengaturan berbeda jauh lebih banyak daripada baris konfigurasinya, jadi putuskan sebelum menyunting profil.

Nama bukan pemasangan

dev tun1 meminta OpenVPN untuk antarmuka bernama itu, dan build ruang pengguna tradisional akan mencoba membukanya. Jika nama tidak mengikuti pola tun atau tap yang biasa, profil juga memerlukan dev-type yang cocok, karena jenisnya tidak pernah disimpulkan dari string. Perangkat TAP bukan perangkat TUN dengan label lain: memasang yang salah entah langsung gagal atau menghasilkan tautan yang membawa frame yang tidak diharapkan siapa pun. Periksa jenisnya sebelum hal lain, karena setiap pemeriksaan berikutnya menganggap kedua sisi sepakat tentangnya. Setelah itu, pastikan prosesnya benar-benar dapat membuka perangkat, bukan sekadar melihatnya.

dev tun1
dev-type tun

Antarmuka jaringan dan /dev/net/tun adalah objek berbeda: yang satu adalah tautan di dalam ruang nama, yang lain adalah perangkat karakter yang dipakai program ruang pengguna untuk memasang. Dokumentasi Linux TUN/TAP menjelaskan jalur pemasangan itu dan aturan kepemilikan untuk perangkat persisten. Shell root yang dapat menjalankan ip link hanya membuktikan shell itu memiliki privilese, bukan bahwa daemon memilikinya. Kepemilikan simpul perangkat, kumpulan kapabilitas layanan, dan pengguna yang menjalankannya semuanya harus selaras sebelum pembukaan berhasil.

Perangkat yang ada dan tidak dapat dibuka adalah masalah kepemilikan, bukan masalah perutean. Perlakukan seperti itu saat men-debug, atau sore hari akan habis untuk membaca tabel rute yang tidak pernah menjadi masalah.

Siapa yang mengonfigurasi tautan: dua model kepemilikan

Pada model pertama OpenVPN mengonfigurasi alamat dan rute sebagai bagian dari menaikkan koneksi. Itu perilaku bawaan dan paling mudah dipahami, karena satu komponen membuat keadaan dan menghapusnya lagi. Pada model kedua pengelola eksternal memiliki antarmuka, dan ifconfig-noexec menghentikan OpenVPN menjalankan perintah konfigurasi alamatnya lalu menyerahkan parameternya ke skrip. Pengelola kemudian harus menerapkan konfigurasi lokal dan peer yang benar sendiri, yang lebih banyak pekerjaan daripada yang disiratkan nama opsi. Memilih di antara keduanya adalah pertanyaan tentang siapa yang boleh mengubah tautan selama tautan itu aktif.

ifconfig-noexec hanya mencakup alamat: tabel perutean tidak disentuh, dan konfigurasi rute menjadi milik route-noexec. Perlakukan kedua direktif sebagai kontrol terpisah dengan pemilik terpisah, karena menetapkan yang satu dan menganggap yang lain adalah sumber umum tautan yang setengah terkonfigurasi. Pilih tepat satu pemilik per lapisan, alamat di satu tempat dan rute di satu tempat. Pengelola jaringan dan pembantu VPN yang keduanya menulis alamat adalah cara pemutusan menghapus keadaan yang masih diandalkan sisi lain.

Periksa perangkat dari ruang nama yang penting

Periksa perangkat dari ruang nama tempat proses VPN berjalan, bukan dari ruang nama tempat shell Anda kebetulan berada. Kedua perintah di bawah menjawab pertanyaan berbeda, dan perbedaannya terlihat ketika host melihat antarmuka yang tidak dilihat kontainer. Jalankan sesuai urutan yang diberikan, karena yang kedua baru bermakna setelah Anda tahu apakah tautannya ada.

ip -details link show dev tun1
ip tuntap show

Perintah pertama mencetak tautan seperti yang dilihat kernel, termasuk flag dan jenis antarmuka, dan begitulah Anda memastikan ini perangkat yang dimaksud. Yang kedua mendaftar entri tun/tap persisten, yang ada tanpa dipegang proses mana pun. Antarmuka yang menunggu pemilik yang dimaksudkan adalah situasi berbeda dari terowongan hidup yang terpasang ke VPN lain, dan hanya yang kedua menjelaskan mengapa pemasangan Anda sendiri gagal. Temukan proses yang memegang perangkat sebelum mengubah apa pun, karena entri persisten dan antarmuka yang sibuk punya perbaikan berbeda.

Dukungan multiqueue adalah susunan driver tertentu dengan persyaratannya sendiri, bukan izin bagi proses yang tidak terkait untuk berbagi satu antarmuka. Sesi hidup milik pemilik lain adalah masalah koordinasi, dan tidak ada penyuntingan profil yang menyelesaikannya.

Dua jenis persistensi

Persistensi kernel dan persist-tun menjelaskan masa hidup yang mudah dicampur dan mahal untuk dikelirukan. Perangkat persisten ada secara independen dari proses apa pun, sehingga bertahan dari penghentian dan dapat dipakai lagi oleh start berikutnya. persist-tun mempertahankan sumber daya melewati reset lunak yang didukung di dalam satu proses OpenVPN, cakrawala yang jauh lebih pendek. Keduanya tidak menjanjikan bahwa menghentikan layanan menyisakan rute dan alamat di tempatnya, dan antarmuka yang tetap terlihat bukan bukti sesi terenkripsi yang berfungsi.

Pastikan juga backend-nya, karena antarmuka yang dibuat sebelumnya tidak menjelaskan implementasi mana yang akan membukanya. Build komunitas yang membawa jalur data langsung akan mencoba memakainya kecuali desainnya menyatakan lain. Di tempat versi mendukung sakelar itu, disable-dco memilih jalur ruang pengguna sebagai gantinya; mesin lama dan klien lain tidak punya direktif semacam itu, jadi simpan syarat versi di samping opsi alih-alih menganggapnya berlaku.

Apa yang rusak saat hanya pengaktifan yang diuji

Kesepakatan kepemilikan dapat lolos uji pertama dan gagal di uji terakhir, yang membuat pengaktifan menjadi pemeriksaan lemah jika berdiri sendiri. Amati dua transisi sebagai gantinya: reset lunak, dan penghentian penuh yang diikuti start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Pengaktifan adalah kasus mudah: unit naik, tautan muncul, dan keluaran status menyebut profil yang dimuat. Pemasangan adalah saat daemon membuka perangkat, jadi jalankan pemeriksaan tautan setelah unit melaporkan aktif, bukan sebelumnya. Jika tautan ada sementara status masih mengaktifkan, Anda sedang melihat perangkat persisten yang belum dipasangi siapa pun, bukan terowongan yang berfungsi. Alirkan lalu lintas nyata melalui tautan sebelum melanjutkan, karena antarmuka terpasang tanpa rute yang dapat dipakai tetap gagal.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Reset lunak seharusnya meninggalkan sesi tetap dapat dipakai dan sumber daya utuh, dan itulah pekerjaan yang dilakukan persist-tun. Penghentian penuh adalah tempat pengelola eksternal menampakkan diri: jika tautan atau alamatnya bertahan dari penghentian, orang lain memilikinya, dan itu entah keadaan yang Anda dokumentasikan atau bug yang baru saja Anda temukan. Catat kedua pengamatan di samping profil, agar perubahan berikutnya dimulai dari bukti, bukan dari diagram.