Apakah WireGuard siap untuk produksi? Jawabannya bukan protokolnya

Orang bertanya apakah WireGuard siap untuk produksi, yang terdengar seperti pertanyaan tentang kriptografi dan sebenarnya pertanyaan tentang lingkungan Anda. Protokolnya sudah ditinjau bertahun-tahun; penerapannya tetap harus menjawab apakah jaringan Anda membawa transportnya, siapa mendaftarkan dan memensiunkan perangkat, dan siapa menambal paket di kedua ujung. Jawaban itu berbeda antara dua server dalam satu rak dan seribu laptop. Protokolnya sama dalam kedua kasus; operasinya tidak.

Pertanyaan di balik pertanyaan

Yang biasanya ingin diketahui orang adalah apakah mereka dapat berkomitmen pada rancangan yang tidak akan mempermalukan mereka dalam enam bulan. Itu pertanyaan penerapan dengan empat bagian, dan setiap bagian dapat gagal secara independen dari yang lain. Menjawab tiga dengan baik tidak menggantikan yang keempat.

Peringatan lama tentang cuplikan pra-rilis adalah fakta tentang cuplikan itu, bukan label permanen pada setiap paket berikutnya. Sama halnya, tidak ada tulisan blog yang dapat menyatakan kombinasi kernel, klien, jaringan, dan staf Anda yang spesifik sudah siap. Pekerjaannya adalah membuat kombinasi itu eksplisit dan memeriksanya.

Perlakukan kesiapan sebagai sekumpulan gerbang yang Anda lewati atau catat sebagai terbuka. Itu mengubah perdebatan menjadi daftar periksa dengan pemilik. Itu juga membuat butir yang terbuka terlihat oleh siapa pun yang menyetujui, bukan terkubur dalam laporan uji coba.

Gerbang satu: jalurnya harus mengangkut UDP

WireGuard mengangkut lalu lintasnya melalui UDP dan mendokumentasikan bahwa ia tidak menyediakan mode TCP atau penyamaran lalu lintas. Rancangan yang bergantung pada tampilannya seperti lalu lintas web biasa, atau pada penggantian port untuk memperoleh perilaku TCP, dibangun di atas asumsi yang tidak didukung perangkat lunaknya.

Jadi gerbang pertama adalah survei, bukan uji pada satu mesin. Daftarkan lingkungan akses tempat pengguna Anda benar-benar bekerja, lalu verifikasi jalur UDP yang disetujui di masing-masing dan putuskan apa yang terjadi bila jalur itu tidak tersedia.

Koneksi yang bekerja dari kantor tidak membuktikan apa pun tentang jaringan hotel, tembok api kampus, atau operator seluler yang menangani UDP secara berbeda. Lingkungan itulah sebabnya penerapan akses jarak jauh gagal setelah uji coba yang berhasil. Uji coba itu tidak salah; ia sempit. Memperluasnya adalah gerbangnya.

Tuliskan juga jalur cadangannya. Jika jawabannya tidak ada jalur cadangan, itu keputusan yang layak dinyatakan lebih awal daripada ditemukan saat perjalanan bisnis.

Gerbang dua: seseorang harus memiliki kuncinya

Peer WireGuard mengautentikasi dengan kunci, satu pasangan per peserta. Itu mudah dijelaskan dan menuntut secara operasional, karena tidak ada apa pun dalam protokol yang mendaftarkan perangkat, melacak siapa memegang kunci mana, atau mencabut akses ketika sebuah laptop hilang. Protokolnya mengasumsikan kuncinya sudah benar, dan kebenaran adalah pekerjaan seseorang.

Sebutkan orang yang mendaftarkan perangkat, catatan yang memetakan kunci publik ke seseorang dan sebuah perangkat, dan prosedur pencabutannya. Jika pencabutan bergantung pada ingatan tentang di mana salinan berkas konfigurasi dipasang, prosedurnya belum selesai.

Pilih satu perangkat selama uji coba dan pensiunkan dari awal sampai akhir. Latihan itu menghasilkan informasi yang lebih berguna daripada uji konektivitas lain, karena mengungkap celah dalam catatan Anda.

Gerbang tiga: paketnya perlu pemelihara

WireGuard dapat datang sebagai implementasi di dalam kernel, sebagai paket distribusi, atau sebagai klien di ruang pengguna, dan masing-masing punya jalur pembaruannya sendiri. Pertanyaan operasionalnya adalah mana yang Anda jalankan, dari mana asalnya, dan siapa yang menerapkan buletin keamanan.

Kami memakai WireGuard bukan inventaris. Itu tidak mengenali paket yang harus ditambal, versi di gerbang, atau orang yang dapat membatalkan pembaruan yang buruk.

Gerbang empat: terimalah beban kerjanya, bukan jabat tangannya

Kriteria penerimaan harus menjelaskan apa yang dilakukan pengguna. Mencapai aplikasi internal, menyelesaikan nama privatnya, ditolak di tujuan yang tidak sah, dan mengikuti perilaku yang ditetapkan saat terowongan mati semuanya dapat diamati, dan jabat tangan yang berhasil bukan salah satunya.

Jalankan pemeriksaan itu melalui perubahan jaringan, mulai ulang perangkat, dan jendela pemeliharaan gerbang, karena pada peralihan itulah penerapan rusak.

Simpan bukti di samping kriteria, termasuk keadaan lokal yang menghasilkannya:

wg show
ss -lunp | grep 51820
ip -4 route get 10.63.0.1

Uji hijau di jaringan tenang dengan satu laptop adalah pengamatan awal. Itu bukan klaim keandalan, dan memperlakukannya sebagai klaim adalah cara rancangan yang bekerja menjadi rancangan yang dipercaya.