Memasang aplikasi Linux terdengar seperti satu instruksi pada Pi tanpa layar, dan itu menyembunyikan pilihan antara dua jalur penerapan dengan batas dukungan berbeda. Satu adalah aplikasi resmi penyedia, yang membawa persyaratan distribusi dan arsitektur sendiri. Yang lain adalah berkas konfigurasi manual yang dipakai klien standar yang sudah dipaketkan sistem operasi. Keduanya mencapai layanan yang sama, dan keduanya tidak dapat dipertukarkan dari segi pemeliharaan.

Pertanyaan arsitektur datang lebih dulu, karena papan 64-bit bisa menjalankan ruang pengguna 32-bit dan aplikasi hanya menyediakan salah satunya.

Dua batas dukungan, bukan dua pemasang

Baca halaman pemasangan penyedia yang terkini untuk aplikasi yang hendak Anda pakai dan cocokkan dengan papan: rilis distribusi, arsitektur paket, dan persyaratan desktop atau sesi apa pun. Pi yang mendukung operasi 64-bit tidak memberi tahu ruang pengguna mana yang terpasang sekarang, dan itulah nilai yang diperiksa manajer paket. dpkg --print-architecture dan uname -m menjawabnya dalam satu baris masing-masing. Jika rilis atau arsitektur di luar kumpulan yang didokumentasikan, aplikasi tidak didukung di sana meskipun terpasang.

Dukungan juga berbeda menurut metode pemaketan. Batasan yang didokumentasikan untuk satu format paket tidak otomatis berlaku untuk build dari repositori, dan distribusi turunan Debian tidak otomatis merupakan lingkungan yang didukung. Paket komunitas dan resep pemasangan lama membawa model pemeliharaan sendiri, yang bisa Anda terima dengan sadar tetapi tidak seharusnya diadopsi secara tidak sengaja.

Apa yang diberikan aplikasi dan tidak diberikan profil

Aplikasi resmi lebih dari sekadar koneksi: biasanya membawa tombol mati penyedia, penanganan DNS, dan tombol fitur, dan penyedia mendukung perilaku itu sebagai satu kesatuan. Profil manual yang diserahkan ke klien standar tidak mewarisi satu pun dari itu. Klien manual memiliki siklus hidup koneksi dan kebijakan kegagalan lokal, yang baik ketika Anda mengaturnya sendiri dan mengejutkan ketika Anda menganggapnya ikut terbawa. Kedua opsi mencapai peladen yang sama; hanya satu yang menyertakan logika di sekitarnya.

Jika suatu fitur penting, misalnya memblokir lalu lintas di luar terowongan, fitur itu harus ada dalam konfigurasi Anda, bukan dalam aplikasi penyedia.

WireGuard secara manual: langkah yang penting

Penyedia mendokumentasikan pembuatan konfigurasi WireGuard untuk klien yang kompatibel standar dan menyarankan jalur itu untuk penyiapan manual, sambil mempertahankan OpenVPN untuk perangkat lama. Buat profil di dasbor akun, bawa ke Pi, dan letakkan di tempat yang hanya bisa dibaca pemilik. Jangan pernah menempelkan berkas ke utas dukungan, karena nama berkas yang ramah tidak membuat kunci privat di dalamnya layak dipublikasikan. Lalu uji terowongan dengan satu permintaan sebelum menghubungkan apa pun yang lain.

Penarikan peladen adalah detail operasional yang orang lupa. Titik akhir yang dipilih manual dapat ditarik, dan penyedia mencatat bahwa konfigurasi pengganti mungkin diperlukan. Catat titik akhir mana yang dipakai profil agar kegagalan kemudian dapat didiagnosis.

Putuskan apakah Pi juga menjadi gerbang

Terowongan yang dipakai aplikasi Pi sendiri tidak otomatis menjadi gerbang bagi perangkat di belakangnya. Penerusan, perutean balik, kepemilikan resoler, dan kebijakan apa pun yang mencegah lalu lintas keluar dari terowongan adalah rancangan terpisah dengan mode kegagalannya sendiri. Jika perangkat lain termasuk cakupan, nilai sebagai kasusnya sendiri alih-alih menganggap koneksi Pi mencakupnya. Pemisahan itulah yang menjaga penerapan kecil tetap terpelihara.

Lalu terima siklus hidupnya: permintaan baru dari Pi, resolusi nama melalui resoler yang dimaksud, dan perilaku boot atau sambung ulang yang Anda rencanakan. Verifikasi masing-masing alih-alih menganggap aplikasi atau profil menyediakannya.

Mitos yang layak ditinggalkan adalah bahwa pemasang Linux dan berkas WireGuard mewakili keputusan yang sama. Keduanya adalah dua model operasi dengan dua pemilik berbeda.

Artikel terkait