Boot pertama: pendaftaran untuk armada perangkat WireGuard

Satu image, satu kunci per papan, dan langkah otorisasi yang tidak memercayai klaim perangkat itu sendiri. Empat tahap dari boot sampai peer yang dikukuhkan.

Papan melakukan boot dari image bersama, mendapat sewa DHCP, dan skrip penyediaan berjalan sebelum siapa pun menyentuh perangkat. Di suatu tempat dalam skrip itu ia harus memperoleh identitas WireGuard yang menjadi milik papan ini dan bukan yang lain, membuat identitas itu diotorisasi, dan menulis profil yang akan diterima gateway. Image boleh membawa perangkat lunak klien, templat yang telah ditinjau, dan kunci publik gateway. Yang tidak boleh pernah dibawanya adalah satu kunci privat yang dipakai bersama seluruh armada, karena itu mengubah satu papan yang dicuri menjadi insiden seluruh armada. Urutan di bawah menjaga identitas tetap lokal dan otorisasi tetap eksplisit.

Apa yang dibawa image, dan apa yang tidak

Kirimkan paket, templat dengan placeholder, kunci publik gateway, dan klien pendaftaran. Templat adalah bentuk, bukan rahasia: templat harus dapat dibaca oleh pengguna penyediaan dan tidak memuat bahan kunci.

Kunci privat dibuat di perangkat pada boot pertama dan tidak pernah meninggalkannya. Hanya separuh publik yang bepergian, di dalam permintaan pendaftaran yang diotorisasi oleh sesuatu selain klaim perangkat itu sendiri tentang siapa dirinya. Perbedaan itulah yang mencegah papan yang dicuri menjadi masalah seluruh armada. Itu juga bagian yang paling sering salah dikerjakan skrip boot pertama.

Langkah 1: buat kunci secara lokal

Jalankan pembuatan di direktori terlindungi setelah koneksi jaringan yang mendasarinya disetujui dan berfungsi. Subshell menjaga perubahan umask tetap lokal untuk operasi ini, dan set -C menolak menimpa berkas yang sudah ada:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

Mulai cepat WireGuard mendokumentasikan hubungan pembuatan kunci yang menjadi landasan kedua perintah ini. Jika pembuatan terputus, biarkan perangkat tidak terdaftar dan biarkan alur kerja merekonsiliasi berkasnya. Jangan hapus identitas yang sudah ada hanya agar skrip berjalan bersih dari awal.

Pertahankan kunci yang tertunda di antara percobaan ulang. Membuat ulang identitas setelah setiap kegagalan jaringan sementara adalah cara sebuah armada berakhir dengan peer yatim yang tidak dapat dicocokkan siapa pun ke perangkat.

Langkah 2: otorisasi catatan perangkat

Anggaplah inventaris menyebut papan ini device-042 dan memberinya 10.90.0.42/32. Layanan pendaftaran harus memverifikasi bahwa pemohon ini berhak atas catatan itu. Nomor seri yang diketik ke dalam formulir bukan bukti, karena nomor seri tercetak di bagian luar kotak.

Kredensial bootstrap per perangkat, persetujuan operator, atau atestasi berbasis perangkat keras dapat menegakkan klaim itu. Lindungi integritas permintaan dan keaslian respons, dan jangan mengganti satu rahasia VPN bersama dengan satu kredensial pabrik bersama.

Catatan yang terdaftar mengikat perangkat, kunci publiknya, alamat yang diberikan, dan peran pengelolaan yang diizinkan. WireGuard sendiri tidak mendefinisikan API pendaftaran, jadi layanan itu adalah sesuatu yang Anda bangun dan operasikan dengan sengaja.

Langkah 3: tulis dua konfigurasi yang cocok

Perangkat memerlukan profil yang merutekan prefiks pengelolaan ke dalam tunnel, dan gateway memerlukan entri peer yang hanya mengizinkan alamat sumber perangkat ini sendiri. Dengan gateway di 10.90.0.1 dan jaringan pengelolaan 10.60.0.0/16, sisi perangkat terlihat seperti ini:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

Nilai di dalam kurung siku adalah placeholder, bukan kunci. Keepalive penting ketika papan berada di belakang NAT dan harus tetap terjangkau; itu tidak diperlukan di semua tempat, dan menambahkannya karena kebiasaan membuat radio tetap terjaga tanpa alasan.

Di gateway, entri peer sengaja sempit:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

Jangan menyalin daftar tujuan perangkat ke peer gateway. Di perangkat daftar itu mengatakan apa yang harus dirutekan ke tunnel; di gateway daftar itu mengatakan alamat sumber mana yang boleh dipakai peer ini, dan itu pernyataan yang berbeda.

Penerusan, aturan firewall, dan jalur balik ke jaringan pengelolaan tetap harus mengizinkan akses yang disetujui. Peer yang terdaftar bukanlah izin untuk setiap aplikasi di belakangnya.

Langkah 4: kukuhkan pendaftaran sebagai status siklus hidup

Terapkan catatan gateway dan profil perangkat melalui pihak yang memiliki masing-masing konfigurasi, lalu tandai pendaftaran selesai hanya ketika identitas dan alamat yang dimaksudkan diterima. Percobaan ulang harus merekonsiliasi catatan yang sama itu alih-alih mengalokasikan peer kedua atau alamat kedua.

Pertahankan jalur pemulihan untuk penyediaan yang terputus, termasuk kasus ketika gateway menerima kunci dan perangkat tidak pernah menulis profilnya.

Ketika papan diganti atau dipensiunkan, hapus kunci publiknya dan otorisasinya bersama-sama. Kunci baru adalah peristiwa pendaftaran ulang yang disengaja, bukan efek samping dari image ulang. Urutan kerja: buat secara lokal, otorisasi terhadap inventaris, tulis kedua sisi, kukuhkan status, lalu uji satu permintaan pengelolaan melalui tunnel.

Artikel terkait