Tiga keputusan alamat sebelum menaruh sensor IoT di belakang VPN
Tiga alamat menjalankan tiga tugas: hub publik, peer situs yang terautentikasi, dan alamat privat sensor. Rencanakan masing-masing sebelum mengalokasikan apa pun yang publik.
Tiga alamat saling terjerat dalam setiap rencana IoT lewat VPN, dan semuanya bukan keputusan yang sama jenisnya. Satu adalah bagaimana operator jarak jauh menemukan titik akhir tunnel, satu adalah bagaimana situs membuktikan bahwa dia memang situs itu, dan satu lagi adalah di mana layanan sensor benar-benar mendengarkan. Jawab ketiganya dalam urutan itu dan desainnya sebagian besar muncul sendiri. Jawab semuanya sebagai satu pertanyaan dan Anda berakhir memberikan alamat publik kepada perangkat yang tidak pernah membutuhkannya. Sensor di belakang tunnel situs keluar dapat dijangkau operator yang berwenang tanpa satu pun aturan masuk yang mengarah ke sensor.
Mulai dari siapa yang memulai
Siapa yang memutar menentukan hampir semua hal setelahnya. Ketika situs memutar ke hub, situs tidak membutuhkan keterjangkauan masuk, dan hub membutuhkan nama atau alamat yang dapat diresolusi situs. Satu pilihan itu menghapus sebagian besar perdebatan pengalamatan publik statis sebelum dimulai.
Ketiga peran lalu terpisah dengan rapi, dan tabel di bawah adalah bentuk terpendek dari keputusan itu.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Setiap baris punya pemilik berbeda, dan itulah intinya. Hub milik siapa pun yang menjalankan layanan VPN, peer situs milik tim jaringan, dan alamat sensor milik siapa pun yang memiliki perangkat.
Alamat hub adalah bootstrap, bukan tujuan
Nama yang meresolusi ke alamat publik terawat sudah cukup bagi hub. Catatan DNS dapat mengikuti titik akhir saat ia pindah, tanpa menyunting setiap konfigurasi situs secara manual. Yang tidak dilakukan DNS adalah menciptakan keterjangkauan atau menyegarkan klien yang menyimpan jawaban lama, dan itu masalah terpisah dengan perbaikan terpisah.
Jika Anda menjalankan tunnel situs-ke-situs tanpa hub, logika yang sama berlaku dalam bentuk lain: satu sisi membutuhkan titik akhir yang dapat dijangkau, atau kedua sisi memutar ke pihak ketiga. Seseorang tetap harus memiliki alamat itu dan perpanjangannya.
Peer situs adalah identitas dengan prefiks yang melekat
Peer adalah identitas dulu dan prefiks kemudian. Dalam istilah WireGuard, peer memegang pasangan kunci dan entri AllowedIPs hub mengikat kunci itu ke prefiks situs. Dalam istilah IKEv2, sertifikat atau kunci yang dibagikan sebelumnya mengidentifikasi situs dan pemilih lalu lintasnya menyatakan apa yang boleh dibawanya. Mengubah salah satu bagian saja merusak susunannya, karena itu perubahan alamat tidak boleh pernah diperlakukan sebagai perubahan identitas.
Pegang kepemilikan kunci atau sertifikat di situs, bukan di operator hub, agar pergantian penyedia tidak menjadi pergantian identitas.
Prefiks adalah bagian yang orang lupa rencanakan. Hub harus mengaitkan subnet sensor dengan peer yang benar, dan klien operator membutuhkan rute ke sana; rute yang hanya ada di klien mengirim lalu lintas ke tunnel yang diam-diam membuangnya. Tulis prefiks di catatan situs di samping sidik jari kunci, agar gateway pengganti tidak dapat muncul dengan cakupan berbeda tanpa diketahui.
Alamat sensor milik aplikasi
Alamat privat dari rencana situs sudah cukup, dan yang dibutuhkannya adalah kestabilan, bukan keterjangkauan publik: reservasi DHCP, penetapan statis, atau nama di zona situs itu sendiri. Jika perangkat tidak dapat dinomori ulang, penerjemahan di gateway situs adalah jawaban yang sah selama penerjemahan didokumentasikan dan lalu lintas balasan mengikutinya.
Satu kebiasaan lain yang layak dipertahankan: jangan pernah menempelkan alamat hub publik ke kolom hop berikutnya pada host sensor. VPN memasang jalurnya sendiri, dan ketetanggaan Ethernet biasa ke titik akhir publik adalah fiksi yang menghasilkan konfigurasi yang tampak meyakinkan.
Balasan adalah separuh yang terlewat. Perangkat harus mengirim jawabannya kembali ke arah tunnel, baik melalui rute ke klien operator maupun melalui gateway yang sama yang menerjemahkan permintaan. Sensor dengan gateway default yang salah menerima permintaan dan menjawab ke dalam kehampaan, dan catatan penerusan menjelaskan mengapa kedatangan dan perutean balasan adalah dua persyaratan, bukan satu.
Putuskan, lalu tulis batasnya
Tulis batas akses sebelum siapa pun terhubung. Batasi gateway ke segmen IoT dan ke layanan tertentu yang dibutuhkan operator, karena rute yang berfungsi cenderung menjadi akses umum secara tidak sengaja. Pegang pemantauan hanya-baca dan wewenang konfigurasi sebagai peran terpisah dengan identitas terpisah, dan sebutkan nama orang yang mencabut akses saat kontrak berakhir.
Persetujuan milik pemilik jaringan, dan berada di DMZ bukan kebijakan akses.
Uji setelah penerapan membosankan dan menentukan: satu permintaan di dalam prefiks yang diizinkan yang berhasil, penghitung yang naik di gateway, dan satu upaya sengaja di luar prefiks yang gagal.