Udostępnij za pośrednictwem

Tworzenie przykładowego środowiska sieciowego dla usługi Azure IoT Layered Network Management (wersja zapoznawcza)

  • Artykuł

Aby użyć usługi Azure IoT Layered Network Management (wersja zapoznawcza), należy skonfigurować izolowane środowisko sieciowe. Na przykład architektura sieci purdue ISA-95/. Ta strona zawiera kilka przykładów konfigurowania środowiska testowego w zależności od tego, jak chcesz osiągnąć izolację.

  • Segmentacja fizyczna — sieci są fizycznie oddzielone. W takim przypadku należy wdrożyć zarządzanie siecią warstwową (wersja zapoznawcza) na hoście podwójnej karty sieciowej (karta interfejsu sieciowego), aby połączyć się zarówno z siecią internetową, jak i izolowaną siecią.
  • Segmentacja logiczna — sieć jest logicznie segmentowana przy użyciu konfiguracji, takich jak sieć VLAN, podsieć lub zapora. Zarządzanie siecią warstwową ma jeden punkt końcowy i jest skonfigurowany tak, aby był widoczny dla własnej warstwy sieciowej i warstwy izolowanej.

Oba podejścia wymagają skonfigurowania niestandardowego systemu DNS w warstwie sieci izolowanej w celu kierowania ruchu sieciowego do wystąpienia warstwy zarządzania siecią w górnej warstwie.

Ważne

Środowiska sieciowe opisane w dokumentacji zarządzania siecią warstwową to przykłady testowania zarządzania siecią warstwową. Nie jest to zalecenie dotyczące tworzenia topologii sieci i klastra na potrzeby środowiska produkcyjnego.

Konfigurowanie izolowanej sieci przy użyciu segmentacji fizycznej

Poniższa przykładowa konfiguracja to prosta izolowana sieć z minimalnymi urządzeniami fizycznymi.

Diagram konfiguracji sieci izolowanej urządzenia fizycznego.

  • Punkt dostępu bezprzewodowego służy do konfigurowania sieci lokalnej i nie zapewnia dostępu do Internetu.
  • Klaster poziomu 4 to klaster z jednym węzłem hostowanym na maszynie fizycznej z podwójną kartą sieciową łączącą się z Internetem i siecią lokalną.
  • Klaster poziomu 3 jest klastrem z jednym węzłem hostowanym na maszynie fizycznej. Ten klaster urządzeń łączy się tylko z siecią lokalną.

Zarządzanie siecią warstwową jest wdrażane w klastrze podwójnej karty sieciowej. Klaster w sieci lokalnej łączy się z zarządzaniem siecią warstwową jako serwer proxy w celu uzyskania dostępu do usług Azure i Arc. Ponadto w sieci lokalnej potrzebna byłaby niestandardowa usługa DNS w celu zapewnienia rozpoznawania nazw domen i wskazywania ruchu do warstwowego zarządzania siecią. Aby uzyskać więcej informacji, zobacz Konfigurowanie niestandardowego systemu DNS.

Konfigurowanie izolowanej sieci z segmentacją logiczną

Na poniższym diagramie przedstawiono izolowane środowisko sieciowe, w którym każdy poziom jest logicznie segmentowany z podsieciami. W tym środowisku testowym istnieje wiele klastrów na każdym poziomie. Klastry mogą być podstawowymi elementami usługi AKS Edge lub K3S. Klaster Kubernetes w sieci poziomu 4 ma bezpośredni dostęp do Internetu. Klastry Kubernetes na poziomie 3 i poniżej nie mają dostępu do Internetu.

Diagram sieci izolowanej segmentacji logicznej.

Wiele poziomów sieci w tej konfiguracji testowej odbywa się przy użyciu podsieci w sieci:

  • Podsieć poziomu 4 (10.104.0.0/16) — ta podsieć ma dostęp do Internetu. Wszystkie żądania są wysyłane do miejsc docelowych w Internecie. Ta podsieć ma jedną maszynę z systemem Windows 11 z adresem IP 10.104.0.10.
  • Podsieć poziomu 3 (10.103.0.0/16) — ta podsieć nie ma dostępu do Internetu i jest skonfigurowana tak, aby miała dostęp tylko do adresu IP 10.104.0.10 w poziomie 4. Ta podsieć zawiera maszynę z systemem Windows 11 z adresem IP 10.103.0.33 i maszyną z systemem Linux, która hostuje serwer DNS. Serwer DNS jest skonfigurowany przy użyciu kroków opisanych w temacie Konfigurowanie niestandardowego systemu DNS. Wszystkie domeny w konfiguracji DNS muszą być mapowane na adres 10.104.0.10.
  • Podsieć poziomu 2 (10.102.0.0/16) — podobnie jak poziom 3, ta podsieć nie ma dostępu do Internetu. Skonfigurowano dostęp tylko do adresu IP 10.103.0.33 na poziomie 3. Ta podsieć zawiera maszynę z systemem Windows 11 z adresem IP 10.102.0.28 i maszyną z systemem Linux, która hostuje serwer DNS. W tej sieci istnieje jedna maszyna z systemem Windows 11 (węzeł) z adresem IP 10.102.0.28. Wszystkie domeny w konfiguracji DNS muszą być mapowane na adres 10.103.0.33.

Zapoznaj się z poniższymi przykładami dotyczącymi konfigurowania tego typu środowiska sieciowego.

Przykład segmentacji logicznej z minimalnym sprzętem

W tym przykładzie oba maszyny są połączone z punktem dostępu (AP), który łączy się z Internetem. Komputer hosta poziomu 4 może uzyskiwać dostęp do Internetu. Host poziomu 3 jest zablokowany do uzyskiwania dostępu do Internetu przy użyciu konfiguracji ap. Na przykład zapora lub kontrola klienta. Ponieważ obie maszyny znajdują się w tej samej sieci, wystąpienie warstwowego zarządzania siecią hostowane w klastrze poziomu 4 jest domyślnie widoczne dla maszyny i klastra poziomu 3. W sieci lokalnej należy skonfigurować dodatkowy niestandardowy system DNS w celu zapewnienia rozpoznawania nazw domen i wskazywania ruchu do warstwowego zarządzania siecią. Aby uzyskać więcej informacji, zobacz Konfigurowanie niestandardowego systemu DNS.

Diagram logicznej izolowanej konfiguracji sieci.

Przykład segmentacji logicznej na platformie Azure

W tym przykładzie środowisko testowe jest tworzone przy użyciu sieci wirtualnej i maszyny wirtualnej z systemem Linux na platformie Azure.

Ważne

Środowisko wirtualne służy tylko do eksploracji i oceny. Aby uzyskać więcej informacji, zobacz obsługiwane środowiska dla operacji usługi Azure IoT.

  1. Utwórz sieć wirtualną w ramach subskrypcji platformy Azure. Utwórz podsieci dla co najmniej dwóch warstw (poziom 4 i poziom 3). Zrzut ekranu przedstawiający sieć wirtualną na platformie Azure.
  2. Opcjonalnie można utworzyć dodatkową podsieć dla serwera przesiadkowego lub maszyny deweloperskiej w celu zdalnego uzyskiwania dostępu do maszyny lub klastra między warstwami. Ta konfiguracja jest wygodna, jeśli planujesz utworzyć więcej niż dwie warstwy sieciowe. W przeciwnym razie możesz połączyć maszynę przesiadkowa z siecią poziomu 4.
  3. Utwórz sieciowe grupy zabezpieczeń dla każdego poziomu i odpowiednio dołącz do podsieci.
  4. Możesz użyć wartości domyślnej dla grupy zabezpieczeń poziomu 4.
  5. Należy skonfigurować dodatkowe reguły ruchu przychodzącego i wychodzącego dla grupy zabezpieczeń poziomu 3 (i niższego poziomu).
    • Dodaj reguły zabezpieczeń dla ruchu przychodzącego i wychodzącego, aby odmówić całego ruchu sieciowego.
    • Z wyższym priorytetem dodaj reguły zabezpieczeń dla ruchu przychodzącego i wychodzącego, aby zezwolić na ruch sieciowy do i z zakresu adresów IP poziomu 4 podsieci.
    • [Opcjonalnie] Jeśli utworzysz podsieć serwera przesiadkowego, utwórz reguły ruchu przychodzącego i wychodzącego, aby umożliwić ruch do i z tej podsieci. Zrzut ekranu przedstawiający grupę zabezpieczeń poziomu 3.
  6. Utwórz maszyny wirtualne z systemem Linux na poziomie 3 i na poziomie 4.
    • Zapoznaj się z obsługiwanymi środowiskami , aby uzyskać informacje o specyfikacji maszyny wirtualnej.
    • Podczas tworzenia maszyny wirtualnej połącz maszynę z podsiecią utworzoną we wcześniejszych krokach.
    • Pomiń tworzenie grupy zabezpieczeń dla maszyny wirtualnej.

konfigurowanie niestandardowego systemu DNS

Niestandardowy system DNS jest wymagany dla poziomu 3 i poniżej. Gwarantuje to, że rozpoznawanie nazw DNS dla ruchu sieciowego pochodzącego z klastra jest wskazywane na wystąpienie zarządzania siecią warstwową na poziomie nadrzędnym. W istniejącym lub produkcyjnym środowisku uwzględnij następujące rozwiązania DNS w projekcie DNS. Jeśli chcesz skonfigurować środowisko testowe dla usługi Zarządzanie siecią warstwową i operacje usługi Azure IoT, zapoznaj się z poniższymi przykładami.

Konfigurowanie sieci CoreDNS

Podczas gdy konfiguracja DNS można osiągnąć na wiele różnych sposobów, w tym przykładzie jest używany mechanizm rozszerzenia udostępniany przez CoreDNS, który jest domyślnym serwerem DNS dla klastrów K3S. Adresy URL na liście dozwolonych, które należy rozwiązać, są dodawane do sieci CoreDNS.

Ważne

Podejście CoreDNS dotyczy tylko klastra K3S na hoście z systemem Ubuntu na poziomie 3.

Tworzenie mapy konfiguracji na poziomie 4 Warstwowe zarządzanie siecią

Gdy klaster poziomu 4 i zarządzanie siecią warstwową są gotowe, wykonaj następujące kroki.

  1. Potwierdź adres IP usługi Zarządzania siecią warstwową za pomocą następującego polecenia:

    kubectl get services -n azure-iot-operations

    Dane wyjściowe powinny wyglądać podobnie do poniższych. Adres IP usługi to 20.81.111.118.

    NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
lnm-level4   LoadBalancer   10.0.141.101   20.81.111.118   80:30960/TCP,443:31214/TCP   29s

  2. Wyświetl mapy konfiguracji za pomocą następującego polecenia:

    kubectl get cm -n azure-iot-operations

    Dane wyjściowe powinny wyglądać podobnie do następującego przykładu:

    NAME                           DATA   AGE
aio-lnm-level4-config          1      50s
aio-lnm-level4-client-config   1      50s

  3. Dostosuj element aio-lnm-level4-client-config. Ta konfiguracja jest wymagana w ramach konfiguracji poziomu 3 w celu przekazywania ruchu z klastra poziomu 3 do wystąpienia zarządzania siecią warstwową najwyższego poziomu.

    # set the env var PARENT_IP_ADDR to the ip address of level 4 LNM instance.
  export PARENT_IP_ADDR="20.81.111.118"

# run the script to generate a config map yaml
  kubectl get cm aio-lnm-level4-client-config -n azure-iot-operations -o yaml | yq eval '.metadata = {"name": "coredns-custom", "namespace": "kube-system"}' -| sed 's/PARENT_IP/'"$PARENT_IP_ADDR"'/' > configmap-custom-level4.yaml

    Ten krok tworzy plik o nazwie configmap-custom-level4.yaml

Konfigurowanie poziomów 3 CoreDNS usługi K3S

Po skonfigurowaniu klastra K3S i przeniesieniu go do warstwy izolowanej na poziomie 3 skonfiguruj wcześniej wygenerowaną konfigurację CoreDNS poziomu 3 K3S z dostosowaną konfiguracją klienta.

  1. Skopiuj element configmap-custom-level4.yaml na host poziomu 3 lub do systemu, w którym uzyskujesz zdalny dostęp do klastra.

  2. Uruchom następujące polecenia:

    # Create a config map called coredns-custom in the kube-system namespace
kubectl apply -f configmap-custom-level4.yaml

# Restart coredns
kubectl rollout restart deployment/coredns -n kube-system

# validate DNS resolution
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net

# You should see the following output.
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup east.servicebus.windows.net
Server:    10.43.0.10
Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local

Name:      east.servicebus.windows.net
Address 1: 20.81.111.118
pod "busybox" deleted

# Note: confirm that the resolved ip address matches the ip address of the level 4 Layered Network Management instance.

  3. Poprzedni krok ustawia konfigurację DNS, aby rozpoznać dozwolone adresy URL w klastrze na poziomie 4. Aby upewnić się, że system DNS poza klastrem działa tak samo, należy skonfigurować systemowo rozpoznawane w celu przekazywania ruchu do sieci CoreDNS wewnątrz klastra K3S. Uruchom następujące polecenia na hoście K3S: Utwórz następujący katalog:

        sudo mkdir /etc/systemd/resolved.conf.d

    Utwórz plik o nazwie z lnm.conf następującą zawartością. Adres IP powinien być adresem IP klastra poziomu 3 usługi kube-dns uruchomionej w przestrzeni nazw kube-system.

    [Resolve]
DNS=<PUT KUBE-DNS SERVICE IP HERE> 
DNSStubListener=no

    Uruchom ponownie program rozpoznawania nazw DNS:

    sudo systemctl restart systemd-resolved

Powiązana zawartość

Co to jest zarządzanie siecią warstwową usługi Azure IoT?