Pi-hole dan VPN di satu Pi: apakah sistem operasinya masih didukung?

Pada kotak gabungan Pi-hole dan VPN, dua hal tercampur: keluarga distribusi yang Anda pasang dan rilis plus arsitektur yang benar-benar didukung komponennya. Papan yang mem-boot image membuktikan kernel berjalan; itu tidak membuktikan bahwa biner FTL Pi-hole dan pemasang VPN Anda menyasar ruang pengguna yang sama. Ujian sebenarnya adalah tumpang tindih empat arah antara dukungan papan, cabang rilis, arsitektur paket, dan jalur peningkatan yang bisa Anda kendalikan sendiri. Kehilangan salah satu dari empat kaki itu dan perangkat bekerja minggu ini, lalu meninggalkan Anda pada pembaruan keamanan berikutnya.

Cabang rilis yang menentukan dukungan, bukan nama keluarga

Tanyakan rilis mana yang masih diuji proyek, lalu tuliskan jawabannya sebagai string versi, bukan Debian. Halaman prasyarat Pi-hole mencantumkan sistem operasi yang didukung dan arsitektur FTL yang sudah dibangun sebagai dua persyaratan terpisah, membatasi dukungan pada rilis yang masih dipelihara distribusi itu sendiri, dan memperingatkan bahwa varian atau konfigurasi tak biasa bisa gagal bahkan di dalam daftar yang didukung. Frasa itu penting: keluarga yang didukung tidak mencakup setiap anggotanya.

Image lama yang masih boot di Pi Anda bukan bukti dukungan. Papannya baik-baik saja, indeks paketnya basi, dan ketidakcocokan muncul kemudian, saat pemasang menarik dependensi yang tidak lagi bisa dipenuhi rilis itu.

Sisi VPN punya lebih banyak bagian, masing-masing dengan jendelanya sendiri: daemon tunnel, pembantu pemasangan yang menulis konfigurasinya, aplikasi klien penyedia, dan paket integrasi distribusi adalah empat proyek terpisah. Pemasang yang mengenali distribusi Anda dan pemasang yang menghasilkan layanan yang bisa dijaga rilis tetap berjalan adalah dua klaim berbeda. Cari daftar platform daemon itu sendiri, lalu cari apakah pembantu yang ingin Anda jalankan pernah disentuh sejak rilis itu terbit. Bila sebuah proyek menyatakan dukungan hanya sampai rilis tertentu, perlakukan rilis berikutnya sebagai belum teruji sampai Anda sendiri mem-boot-nya.

Cocokkan target biner dengan ruang pengguna yang Anda miliki

Arsitektur adalah kegagalan yang lebih senyap. Kernel 64-bit dengan ruang pengguna 32-bit adalah kombinasi nyata dan didukung di beberapa papan, dan ia menjalankan biner FTL 32-bit tanpa keluhan, sampai saat Anda memasang sesuatu yang hanya diterbitkan untuk arm64. Cetak kedua belahannya sebelum memilih image, dan simpan keluarannya di samping catatan Anda.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

Jika dua baris arsitektur itu tidak sepakat, Anda berada pada penyiapan campuran: bisa jalan untuk Pi-hole saja, rapuh begitu layanan kedua menuntut pustaka asli. Mem-flash ulang ke image 64-bit yang bersih biasanya lebih cepat daripada membangun ulang rantai alat yang menghasilkan ketidakcocokan.

Pemasaran papan juga tidak menyelesaikan ini. Ukuran memori dan model CPU tidak mengatakan apa pun tentang libc mana paket Anda ditautkan, jadi putuskan dari nilai yang tercetak, jangan pernah dari halaman produk.

Satu kotak, dua layanan, satu pemilik jaringan

Putuskan siapa yang memiliki pengalamatan, resolver, dan tunnel sebelum paket pertama dipasang, karena jika tidak dua layanan akan mengklaim tugas yang sama dan tak satu pun menang bersih. Beri Pi alamat statis di luar kumpulan DHCP yang dibagikan router Anda, dan pertahankan tunnel pada subnetnya sendiri: 192.168.50.10 untuk Pi dan 10.42.0.0/24 untuk tunnel adalah satu pembagian yang bisa jalan, dan angka-angkanya sendiri sewenang-wenang asalkan tidak bertabrakan dengan yang sudah dilayani router Anda. Lalu tuliskan komponen mana yang menjawab di port 53, mana yang membagikan DHCP jika Anda memakainya, dan mana yang memiliki rute default selama tunnel hidup. Pada image tanpa layar, tugas terakhir itu milik NetworkManager atau systemd-networkd, dan memasang klien penyedia yang juga menulis ulang konfigurasi resolver adalah cara orang berakhir dengan tunnel hidup dan DNS mati.

Berbagi kotak itu wajar. Berbagi peran tidak. Pi-hole ingin menjadi satu-satunya pendengar di port 53, dan daemon VPN ingin mendorong pengaturan DNS-nya sendiri ke klien, jadi pilih mana dari keduanya yang harus dipercaya klien dan konfigurasikan yang lain agar menyingkir.

Jauhkan jalur administrasi dari tunnel bila bisa. Jika resolver dan tunnel gagal bersamaan, Anda tetap ingin SSH terjangkau di alamat LAN, dan itu berarti layanan manajemen tidak boleh bergantung pada salah satunya.

Jadikan peningkatan berikutnya bagian dari pilihan

Rilis yang tidak bisa Anda tingkatkan adalah langit-langit dukungan yang sudah Anda terima. Uji mekanika peningkatan pada kartu cadangan sebelum perangkat memikul DNS rumah Anda, dan baca apa kata proyek tentang melompat antar cabang alih-alih menganggap peningkatan paket sudah cukup.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Paket yang ditahan adalah alasan biasa sebuah peningkatan tampak berhasil dan tidak mengubah apa pun. Lepaskan penahanan dengan sengaja, satu per satu, dan catat layanan mana yang membutuhkan pin itu.

Sebelum lompatan, ekspor konfigurasi Pi-hole, sewa statis, dan profil tunnel apa pun, lalu pastikan Anda bisa memulihkannya pada image baru. Setelah lompatan, uji DNS klien biasa, sumber daya privat di balik tunnel, sambung ulang, dan aturan penerusan apa pun di gateway. Kotak yang boot dan menjawab ping hampir tidak lulus apa pun.

Ketika tidak ada satu rilis pun yang cocok untuk kedua layanan

Kadang tumpang tindihnya kosong: pembantu VPN sudah pindah ke rilis yang lebih baru daripada paket Pi-hole yang bisa Anda pasang, atau image vendor papan tertinggal dari keduanya. Dalam kasus itu pisahkan perannya alih-alih menyunting metadata rilis demi memuaskan pemasang. Dua perangkat kecil, atau satu perangkat plus kontainer untuk layanan kedua, lebih murah daripada perangkat yang kisah dukungannya bergantung pada kebohongan.

Memalsukan versi adalah satu-satunya jalan pintas yang harus ditolak mentah-mentah. Manajer paket percaya pada apa kata berkas rilis, jadi pengenal palsu memberi Anda pemasangan yang tak akan dibantu di-debug oleh kedua proyek itu.

Jika dua rilis terkini memenuhi semuanya, pilih yang catatan peningkatannya bisa Anda ikuti tanpa menebak, dan berhentilah mencari. Lalu catat versi, arsitektur, pemilik layanan, dan langkah pemulihan di satu tempat, karena orang berikutnya yang menyentuh kartu SD akan memerlukan keempatnya.