IoT sensörlerini VPN arkasına koymadan önce üç adres kararı
Üç adres üç iş yapar: genel merkez, kimliği doğrulanmış saha eşi ve sensörün özel adresi. Herhangi bir genel adres ayırmadan önce her birini planlayın.
Her IoT-VPN planında üç adres birbirine dolaşır ve bunlar aynı tür karar değildir. Biri uzak operatörün tünelin uç noktasını nasıl bulduğudur, biri sahanın bu saha olduğunu nasıl kanıtladığıdır, biri de sensörün hizmetinin gerçekte nerede dinlediğidir. Bu sırayla yanıtlayın, tasarım çoğunlukla kendiliğinden çıkar. Tek bir soru olarak yanıtlayın, hiç ihtiyaç duymamış cihazlara genel adresler atamakla sonuçlanırsınız. Giden saha tünelinin arkasındaki sensör, sensöre işaret eden hiçbir gelen kural olmadan yetkili bir operatör tarafından erişilebilir.
Kimin başlattığıyla başlayın
Kimin aradığı sonraki neredeyse her şeyi belirler. Saha bir merkeze bağlandığında sahanın gelen erişilebilirliğe ihtiyacı yoktur ve merkezin sahanın çözebileceği bir ad veya adrese ihtiyacı vardır. Bu tek seçim, statik genel adresleme tartışmasının çoğunu başlamadan ortadan kaldırır.
Üç rol sonra temiz biçimde ayrılır ve aşağıdaki tablo kararın en kısa biçimidir.
| 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 |
Her satırın farklı bir sahibi vardır ve asıl mesele budur. Merkez VPN hizmetini işletenindir, saha eşi ağ ekibinindir ve sensörün adresi cihaza sahip olanındır.
Merkez adresi başlangıçtır, hedef değildir
Bakımlı bir genel adrese çözülen bir ad merkez için yeterlidir. Bir DNS kaydı uç nokta taşındığında onu izleyebilir, her saha yapılandırmasını elle düzenlemeye gerek kalmadan. DNS'in yapmadığı şey erişilebilirlik yaratmak veya eski yanıtı önbelleğe alan istemciyi yenilemektir ve bunlar ayrı sorunlardır, ayrı çözümlerle.
Merkez olmadan saha-sahaya tüneller işletiyorsanız aynı mantık başka bir biçimde geçerlidir: bir taraf erişilebilir bir uç noktaya ihtiyaç duyar ya da iki taraf da üçüncü bir tarafı arar. Birinin o adrese ve yenilemelerine yine de sahip olması gerekir.
Saha eşi, ön ek takılı bir kimliktir
Eş önce kimlik, ikinci olarak ön ektir. WireGuard terimleriyle eş bir anahtar çifti tutar ve merkezin AllowedIPs girdisi o anahtarı sahanın ön ekine bağlar. IKEv2 terimleriyle bir sertifika veya önceden paylaşılan anahtar sahayı tanımlar ve trafik seçicileri neleri taşıyabileceğini söyler. Yalnızca bir yarıyı değiştirmek düzeni bozar, bu yüzden adres değişikliği asla kimlik değişikliği olarak ele alınmamalıdır.
Anahtarın veya sertifikanın mülkiyetini merkez operatöründe değil sahada tutun, böylece sağlayıcı değişikliği kimlik değişikliğine dönüşmesin.
Ön ek, planlanması unutulan kısımdır. Merkez sensörün alt ağını doğru eşe bağlamalıdır ve operatörün istemcisi oraya bir yol ister; yalnızca istemcide bulunan bir yol, trafiği sessizce düşüren bir tünele gönderir. Ön eki anahtar parmak izinin yanına saha kaydına yazın, böylece değiştirilen bir ağ geçidi kimse fark etmeden farklı bir kapsamla ortaya çıkamaz.
Sensörün adresi uygulamaya aittir
Saha planından özel bir adres yeterlidir ve ihtiyaç duyduğu şey genel erişilebilirlik değil kararlılıktır: bir DHCP rezervasyonu, statik atama veya sahanın kendi bölgesindeki bir ad. Cihaz yeniden numaralandırılamıyorsa, saha ağ geçidinde çeviri meşru bir yanıttır; yeter ki çeviri belgelensin ve dönüş trafiği onu izlesin.
Saklamaya değer bir alışkanlık daha: merkezin genel adresini asla sensörün ana bilgisayarındaki sonraki atlama alanına yapıştırmayın. VPN kendi yolunu kurar ve genel bir uç noktaya sıradan Ethernet komşuluğu, inandırıcı görünen yapılandırma üreten bir kurgudur.
Yanıtlar atlanan yarıdır. Cihaz yanıtını tünele doğru geri göndermelidir; ya operatörün istemcisine giden bir yol üzerinden ya da isteği çeviren aynı ağ geçidi üzerinden. Yanlış varsayılan ağ geçidine sahip bir sensör isteği kabul eder ve hiçliğe yanıt verir, ve yönlendirme notları varış ile yanıt yönlendirmesinin neden bir değil iki gereksinim olduğunu açıklar.
Karar verin, sonra sınırı yazın
Erişim sınırını kimse bağlanmadan önce yazın. Ağ geçidini IoT segmentine ve operatörün ihtiyaç duyduğu belirli hizmetlere sınırlayın, çünkü çalışan bir yol kazara genel erişime dönüşme eğilimindedir. Yalnızca okuma izlemeyi ve yapılandırma yetkisini ayrı kimliklere sahip ayrı roller olarak tutun ve sözleşme bittiğinde erişimi kaldıran kişiyi adlandırın.
Onay ağ sahibine aittir ve DMZ'de bulunmak bir erişim politikası değildir.
Kurulum sonrası test sıkıcı ve kesindir: izin verilen ön ek içinde başarılı olan bir istek, ağ geçidinde artan bir sayaç ve ön ek dışında kasıtlı olarak yapılan ve başarısız olan bir deneme.