IoT sensorlarını VPN arxasına qoymazdan əvvəl üç ünvan qərarı
Üç ünvan üç iş görür: ictimai hub, təsdiqlənmiş sayt həmyaşıdı və sensorun şəxsi ünvanı. Hər hansı ictimai ünvan ayırmazdan əvvəl hər birini planlaşdırın.
Hər IoT-VPN planında üç ünvan bir-birinə qarışır və onlar eyni cür qərar deyil. Biri uzaq operatorun tunel son nöqtəsini necə tapmasıdır, biri saytın özünün sayt olduğunu necə sübut etməsidir, biri isə sensorun xidmətinin həqiqətən harada dinləməsidir. Onları bu sıra ilə cavablandırın və dizayn demək olar ki, özü çıxır. Onları tək sual kimi cavablandırsanız, heç vaxt ehtiyac duymayan cihazlara ictimai ünvanlar təyin etməklə nəticələnirsiniz. Çıxan sayt tunelinin arxasındakı sensor, sensoru göstərən heç bir giriş qaydası olmadan səlahiyyətli operator tərəfindən əlçatan olur.
Kimin başlatdığı ilə başlayın
Kim zəng edirsə, sonrakı demək olar ki, hər şeyi müəyyən edir. Sayt hub-a çıxış edəndə saytın giriş əlçatanlığına ehtiyacı yoxdur, hub-un isə saytın həll edə biləcəyi ada və ya ünvana ehtiyacı var. Bu tək seçim statik ictimai ünvanlama mübahisəsinin çoxunu başlamazdan əvvəl aradan qaldırır.
Üç rol sonra təmiz ayrılır və aşağıdakı cədvəl qərarın ən qısa formasıdır.
| 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 |
Hər sətrin fərqli sahibi var və əsas məqam da budur. Hub VPN xidmətini idarə edənə, sayt həmyaşıdı şəbəkə komandasına, sensor ünvanı isə cihazın sahibinə aiddir.
Hub ünvanı təyinat deyil, başlanğıcdır
Baxılan ictimai ünvana həll olunan ad hub üçün kifayətdir. DNS qeydi son nöqtəni köçəndə izləyə bilər, hər sayt konfiqurasiyasını əl ilə redaktə etmədən. DNS-in etmədiyi şey əlçatanlıq yaratmaq və ya köhnə cavabı keşləyən müştərini yeniləməkdir və bunlar ayrı həlləri olan ayrı problemlərdir.
Hub olmadan sayt-sayt tunelləri işlədirsinizsə, eyni məntiq fərqli formada qüvvədə qalır: bir tərəfə əlçatan son nöqtə lazımdır, ya da hər iki tərəf üçüncü tərəfə zəng edir. Kimsə hələ də o ünvanın və onun yenilənmələrinin sahibi olmalıdır.
Sayt həmyaşıdı özünə prefiks bağlanmış kimlikdir
Həmyaşıd əvvəla kimlik, ikincisi prefiksdir. WireGuard baxımından həmyaşıd açar cütünü saxlayır və hub-un AllowedIPs qeydi həmin açarı saytın prefiksinə bağlayır. IKEv2 baxımından sertifikat və ya əvvəlcədən paylaşılan açar saytı tanıdır və onun trafik seçiciləri nəyi daşıya biləcəyini bildirir. Yalnız bir yarısını dəyişmək düzümü pozur, buna görə ünvan dəyişikliyi heç vaxt kimlik dəyişikliyi kimi qəbul edilməməlidir.
Açarın və ya sertifikatın sahibliyini hub operatorunda deyil, saytda saxlayın ki, provayder dəyişikliyi kimlik dəyişikliyinə çevrilməsin.
Prefiks insanların planlaşdırmağı unutduğu hissədir. Hub sensor alt şəbəkəsini düzgün həmyaşıdla əlaqələndirməlidir və operatorun müştərisi bunun üçün marşrut tələb edir; yalnız müştəridə mövcud olan marşrut trafiki səssizcə atan tunelə göndərir. Prefiksi açar barmaq izinin yanında sayt qeydinə yazın ki, dəyişdirilmiş şlüz fərqli əhatə ilə gözlənilmədən qalxa bilməsin.
Sensor ünvanı tətbiqə aiddir
Sayt planından şəxsi ünvan kifayətdir və ona lazım olan ictimai əlçatanlıq deyil, sabitlikdir: DHCP rezervasiyası, statik təyinat və ya saytın öz zonasında ad. Cihazı yenidən nömrələmək mümkün deyilsə, sayt şlüzündə tərcümə qanuni cavabdır, bu şərtlə ki, tərcümə sənədləşdirilib və geri trafik onu izləyir.
Saxlamağa dəyər daha bir vərdiş: ictimai hub ünvanını heç vaxt sensorun hostunda növbəti-hopp sahəsinə yapışdırmayın. VPN öz yolunu qurur və ictimai son nöqtəyə adi Ethernet qonşuluğu inandırıcı görünən konfiqurasiya yaradan bir uydurmadır.
Cavablar atlanan yarıdır. Cihaz cavabını tunelə doğru geri göndərməlidir, ya operatorun müştərisinə marşrutla, ya da sorğunu tərcümə edən eyni şlüz vasitəsilə. Səhv standart şlüzü olan sensor sorğunu qəbul edir və heç yerə cavab verir, və yönləndirmə qeydləri gəliş və cavab marşrutlaşdırmasının niyə bir deyil, iki tələb olduğunu izah edir.
Qərar verin, sonra sərhədi yazın
Giriş sərhədini heç kim qoşulmazdan əvvəl yazın. Şlüzü IoT seqmentinə və operatorun ehtiyac duyduğu konkret xidmətlərə məhdudlaşdırın, çünki işləyən marşrut təsadüfən ümumi girişə çevrilməyə meyyllidir. Yalnız-oxuma monitorinqini və konfiqurasiya səlahiyyətini ayrı kimlikləri olan ayrı rollar kimi saxlayın və müqavilə bitəndə girişi silən şəxsin adını yazın.
Təsdiq şəbəkə sahibinə aiddir və DMZ-də olmaq giriş siyasəti deyil.
Yerləşdirmədən sonra sınaq darıxdırıcı və qətidir: icazə verilən prefiks daxilində uğurla keçən bir sorğu, şlüzdə artan bir sayğac və prefiksdən kənarda qəsdən edilən bir cəhdin uğursuzluğu.