Trzy decyzje o adresach, zanim umieścisz czujniki IoT za VPN

Trzy adresy plączą się w każdym planie IoT przez VPN i nie są tym samym rodzajem decyzji. Jeden to sposób, w jaki zdalny operator znajduje punkt końcowy tunelu, drugi to sposób, w jaki witryna dowodzi, że jest witryną, a trzeci to miejsce, w którym usługa czujnika naprawdę nasłuchuje. Odpowiedz na nie w tej kolejności, a projekt w większości wyjdzie sam. Odpowiedz na nie jako na jedno pytanie, a skończysz na przydzielaniu publicznych adresów urządzeniom, które nigdy ich nie potrzebowały. Czujnik za wychodzącym tunelem witryny jest osiągalny dla upoważnionego operatora bez żadnej reguły przychodzącej wskazującej na czujnik.

Zacznij od tego, kto inicjuje

Kto wybiera, decyduje o prawie wszystkim dalej. Gdy witryna wybiera połączenie z koncentratorem, witryna nie potrzebuje osiągalności przychodzącej, a koncentrator potrzebuje nazwy lub adresu, który witryna potrafi rozwiązać. Ten jeden wybór usuwa większość sporu o statyczne publiczne adresowanie, zanim się zacznie.

Trzy role rozdzielają się wtedy czysto, a tabela poniżej jest najkrótszą formą decyzji.

Każdy wiersz ma innego właściciela i to jest sedno. Koncentrator należy do tego, kto prowadzi usługę VPN, partner witryny do zespołu sieciowego, a adres czujnika do tego, kto posiada urządzenie.

Adres koncentratora to rozruch, nie cel

Nazwa, która rozwiązuje się na utrzymywany publiczny adres, wystarcza koncentratorowi. Rekord DNS może podążać za punktem końcowym, gdy ten się przenosi, bez ręcznego edytowania każdej konfiguracji witryny. Czego DNS nie robi, to tworzenie osiągalności lub odświeżanie klienta, który buforuje starą odpowiedź, i to są osobne problemy z osobnymi rozwiązaniami.

Jeśli prowadzisz tunele witryna-do-witryny bez koncentratora, ta sama logika obowiązuje w innej formie: jedna strona potrzebuje osiągalnego punktu końcowego albo obie strony łączą się z osobą trzecią. Ktoś nadal musi posiadać ten adres i jego odnowienia.

Partner witryny to tożsamość z dołączonym prefiksem

Partner jest najpierw tożsamością, a po drugie prefiksem. W terminach WireGuard partner trzyma parę kluczy, a wpis AllowedIPs koncentratora wiąże ten klucz z prefiksem witryny. W terminach IKEv2 certyfikat lub klucz współdzielony z góry identyfikuje witrynę, a jej selektory ruchu mówią, co może przenosić. Zmiana tylko jednej połowy psuje układ, dlatego zmiana adresu nigdy nie może być traktowana jako zmiana tożsamości.

Trzymaj własność klucza lub certyfikatu po stronie witryny, a nie operatora koncentratora, żeby zmiana dostawcy nie stała się zmianą tożsamości.

Prefiks to część, o której planowaniu ludzie zapominają. Koncentrator musi powiązać podsieć czujnika z właściwym partnerem, a klient operatora potrzebuje do niej trasy; trasa istniejąca tylko na kliencie wysyła ruch do tunelu, który go po cichu odrzuca. Zapisz prefiks w rekordzie witryny obok odcisku klucza, żeby wymieniona brama nie mogła pojawić się z innym zasięgiem niezauważenie.

Adres czujnika należy do aplikacji

Prywatny adres z planu witryny wystarcza, a potrzebna jest mu stabilność, a nie publiczna osiągalność: rezerwacja DHCP, przypisanie statyczne lub nazwa w strefie samej witryny. Jeśli urządzenia nie można przenumerować, tłumaczenie na bramie witryny jest uzasadnioną odpowiedzią, o ile tłumaczenie jest udokumentowane, a ruch powrotny je śledzi.

Jeszcze jeden nawyk wart zachowania: nigdy nie wklejaj publicznego adresu koncentratora w pole następnego skoku na hoście czujnika. VPN instaluje własną ścieżkę, a zwykłe sąsiedztwo Ethernet z publicznym punktem końcowym to fikcja, która daje przekonująco wyglądającą konfigurację.

Odpowiedzi to ta połowa, która bywa pomijana. Urządzenie musi wysłać swoją odpowiedź z powrotem w stronę tunelu, albo trasą do klienta operatora, albo przez tę samą bramę, która przetłumaczyła żądanie. Czujnik z niewłaściwą bramą domyślną przyjmuje żądanie i odpowiada w pustkę, a uwagi o przekazywaniu wyjaśniają, dlaczego przybycie i trasowanie odpowiedzi to dwa wymagania, a nie jedno.

Zdecyduj, a potem zapisz granicę

Zapisz granicę dostępu, zanim ktokolwiek się połączy. Ogranicz bramę do segmentu IoT i do konkretnych usług potrzebnych operatorowi, bo działająca trasa ma zwyczaj przypadkiem stawać się ogólnym dostępem. Utrzymuj monitorowanie tylko do odczytu i uprawnienia konfiguracyjne jako odrębne role z odrębnymi tożsamościami i wskaż osobę, która usuwa dostęp po wygaśnięciu umowy.

Zatwierdzenie należy do właściciela sieci, a przebywanie w DMZ nie jest polityką dostępu.

Test po wdrożeniu jest nudny i rozstrzygający: jedno żądanie wewnątrz dozwolonego prefiksu, które się udaje, licznik, który rośnie na bramie, i jedna świadoma próba poza prefiksem, która zawodzi.