Zarządzanie zaporą hosta za pomocą usługi Azure IoT i OSConfig

Ważne

Wersja 1.0.3 (opublikowana 28 czerwca 2022 r.) obejmuje zmiany powodujące niezgodność nazw członków, które mogą mieć wpływ na istniejących użytkowników. Aby uzyskać więcej informacji, zobacz: Nazwy składowe przechodzą z PascalCase do camelCase w wersji 1.0.3

Grupy odbiorców

Ten artykuł jest przeznaczony do obsługi osób, które aprowizują urządzenia lub zarządzają nimi za pomocą usługi Azure IoT. Jeśli to nie brzmi jak ty, rozważ zapoznanie się z dokumentacją Grupy odbiorców dla konfiguracji systemu operacyjnego.

Omówienie zapory

Po zainstalowaniu konfiguracji systemu operacyjnego urządzenia można użyć usług Azure IoT do wykonywania kilku podstawowych zadań administracyjnych zapory. Przykład:

• Sprawdzanie, czy zapora jest aktywna
• Upewnij się, że istnieją pewne reguły (utwórz, jeśli nie istnieje)
• Upewnij się, że niektóre reguły nie istnieją (usuń, jeśli znaleziono)
• Porównanie reguł wielu wdrożonych urządzeń ze znanym dobrym urządzeniem
• Ustawianie domyślnych zasad ruchu dla ruchu przychodzącego i wychodzącego

Porada

Jeśli jesteś tutaj w dokumentacji modelu obiektów, możesz pominąć przykłady Przypadków użycia do informacji referencyjnych

Przykłady przypadków użycia

Te przykłady mogą służyć jako punkty początkowe, aby dostosować się do unikatowego środowiska.

Każdy przykład zawiera kroki i przechwytywanie ekranu do pracy w Azure Portal oraz do pracy w powłoce bash przy użyciu interfejsu wiersza polecenia platformy Azure.

Każdy przykład zawiera również odmiany dla jednego urządzenia (np. scenariusz rozwiązywania problemów) lub dla wielu urządzeń (np. scenariusz aprowizacji konfiguracji lub raportowania).

Czego można oczekiwać:

W ramach instrukcji dotyczących jednego urządzenia odczytasz i zapiszesz zgłoszone i żądane właściwości bezpośrednio w bliźniaczej reprezentacji systemu operacyjnego dla urządzenia. W instrukcjach na dużą skalę użyjesz konfiguracji IoT Hub (znanych również jako Automatyczne Zarządzanie urządzeniami lub ADM), aby wypchnąć żądane właściwości do wielu bliźniaczych reprezentacji i użyć zapytań IoT Hub (niezależnie lub dołączonych do konfiguracji jako metryk), aby obserwować wyniki pochodzące z urządzeń.

Wymagania wstępne dotyczące wypróbowania przykładów w systemach na żywo

Jeśli używasz tego artykułu do celów referencyjnych, nie ma żadnych wymagań wstępnych. Możesz przejrzeć przykłady, skopiować nazwy właściwości itp.

Jeśli chcesz wypróbować przykłady w systemach na żywo (zalecane), wykonaj następujące kroki:

1. Tworzenie bezpłatnego konta platformy Azure lub używanie istniejącego konta

2. Łączenie co najmniej jednego urządzenia z włączoną konfiguracją systemu operacyjnego z IoT Hub

   Porada

   Aby łatwo utworzyć IoT Hub z dołączonymi urządzeniami wirtualnymi, zobacz Tworzenie środowiska laboratoryjnego OSConfig (za pomocą usługi Azure IoT) w ciągu 5 minut

3. Przygotuj się do korzystania z instrukcji Azure Portal lub instrukcji interfejsu wiersza polecenia platformy Azure w przykładach:

Jeśli wolisz używać Azure Portal

1. Zaloguj się do Azure Portal i uzyskaj dostęp do strony Przegląd IoT Hub

-OR — jeśli wolisz używać interfejsu wiersza polecenia platformy Azure

1. ZALECANE: Użyj usługi Azure Cloud Shell jako środowiska powłoki bash, logując się do witryny Azure Portal, a następnie uruchamiając usługę Azure Cloud Shell w trybie
2. ALTERNATYWA: Jeśli wolisz używać własnego środowiska powłoki bash, a nie Cloud Shell, zainstaluj interfejs wiersza polecenia platformy Azure i zaloguj się
3. Upewnij się, że rozszerzenie Azure IoT jest gotowe, uruchamiając polecenie az extension add --name azure-iot

---

Przykład A. Czy zapora hosta jest aktywna?

Właściwość state w obszarze properties.reported.Firewall daje ogólne wskazanie, czy zapora hosta jest aktywna. Na przykład wskazuje, czy aparat zapory hosta jest włączony, a co najmniej jedna reguła istnieje w tabeli FILTER . Aby uzyskać więcej informacji na temat state dołączania możliwych wartości, zobacz: Informacje referencyjne.

Portal: określone urządzenie

1. Na stronie portalu IoT Hub wybierz pozycję Urządzenia w obszarze nawigacji po lewej stronie. Jeśli urządzenie IoT Edge zainstalowane oprócz konfiguracji systemu operacyjnego, wybierz pozycję IoT Edge zamiast urządzeń.

2. Kliknij urządzenie, na którym jest zainstalowana konfiguracja systemu operacyjnego.

3. W obszarze Tożsamości modułów kliknij pozycję osconfig.

4. Kliknij pozycję Bliźniacza reprezentacja tożsamości modułu i przejdź do pliku JSON do properties.reported.Firewall.state. W poniższym przykładzie przechwytywania ekranu widać, że state: enabled.

   

Portal: na dużą skalę

1. Na stronie portalu Azure IoT Hub wybierz pozycję Zarządzanie urządzeniami —>zapytania w obszarze nawigacji po lewej stronie.

2. Wykonaj następujące zapytanie, aby sprawdzić, czy zapora jest włączona, czy nie dla floty urządzeń podłączonych do Azure IoT Hub.

   SELECT deviceId, properties.reported.Firewall.state AS firewallState    
   FROM devices.modules
   WHERE moduleId='osconfig' 
   

   

Interfejs wiersza polecenia: określone urządzenie

1. Użyj następującego przykładowego polecenia, które pobiera state właściwość dla określonego urządzenia, zastępując <identyfikator> urządzenia i/lub <nazwę> centrum w celu dopasowania do środowiska.

   az iot hub query -q \
   "SELECT properties.reported.Firewall.state AS firewallState   
   FROM devices.modules
   WHERE moduleId='osconfig' AND deviceId = <device-id>" \
    --hub-name <hub-name> --output table
   

   W tym przykładzie przechwytywania ekranu zapora urządzenia jest aktywna i włączona.

   

Interfejs wiersza polecenia: na dużą skalę

1. Użyj następującego przykładowego polecenia, które pobiera state właściwość dla floty urządzeń, zastępując <identyfikator> urządzenia i/lub <nazwę> centrum w celu dopasowania do środowiska.

   az iot hub query -q \
   "SELECT deviceId, properties.reported.Firewall.state AS firewallState   
   FROM devices.modules
   WHERE moduleId='osconfig'" --hub-name <hub-name> --output table
   

   

Przykład B. Tworzenie reguły zapory

W tym przykładzie użyto desiredRules funkcji modułu Zapora. Tworzymy nową regułę zezwalającą na ruch wychodzący tcp 443 z urządzenia do podsieci 10.9.9.0/24.

Aby uzyskać więcej informacji na temat desiredRules (w tym obsługi wielu reguł i usuwania reguł), zobacz Dokumentacja żądań rules zapory w dalszej części tego artykułu.

Portal: określone urządzenie

1. Za pomocą witryny Azure Portal w bliźniaczej reprezentacji modułu osconfig urządzenia dodaj properties.desired lub zmodyfikuj Firewall węzły i desiredRules w następujący sposób. Na standardy JSON może być konieczne dodanie przecinka na końcu, aby zintegrować z innymi żądanymi właściwościami, jeśli są obecne.

   "Firewall": {
      "desiredRules": [
         {
            "desiredState": "present",
            "action": "accept",
            "direction": "out",
            "protocol": "tcp",
            "destinationAddress": "10.9.9.0/24",
            "destinationPort": 443
         }
      ]
   }
   

   

2. Po około 30 sekundach możesz sprawdzić, czy zmiana została pomyślnie wprowadzona z samej reprezentacji bliźniaczej modułu. Odśwież widok bliźniaczej reprezentacji modułu, a następnie przewiń, aby znaleźć properties, a reportednastępnie , a następnie FirewallconfigurationStatusstate , i desiredRules.

   

Portal: na dużą skalę

1. Na stronie portalu Azure IoT Hub wybierz pozycję Zarządzanie urządzeniami -->Konfiguracje -->Dodaj konfigurację modułu.

2. Określ nazwę profilu konfiguracji, a następnie ustaw ustawienia bliźniaczej reprezentacji z żądaną konfiguracją: Ustaw właściwość bliźniaczej reprezentacji modułu naproperties.desired.Firewall i ustaw zawartość właściwości bliźniaczej reprezentacji modułu na następujące:

   "desiredRules": [
      {
         "desiredState": "present",
         "action": "accept",
         "direction": "out",
         "protocol": "tcp",
         "destinationAddress": "10.9.9.0/24",
         "destinationPort": 443
      }
   ]
   

3. W przypadku modułów docelowych określ kryteria, dla których urządzenia znajdują się w zakresie. W tym przykładzie będziemy kierować wszystkie urządzenia z włączoną konfiguracją systemu operacyjnego, określając warunek docelowyFROM devices.modules where moduleId='osconfig'

4. Utwórz metrykę niestandardową z nazwą pomyślnie skonfigurowaną i kryteria metryki , jak pokazano poniżej. To zapytanie metryk będzie identyfikować wszystkie urządzenia, które pomyślnie zaktualizowały konfigurację.

   SELECT deviceId FROM devices.modules 
   WHERE properties.reported.Firewall.desiredRules.ac = 200
   AND properties.reported.Firewall.configurationStatus = 'success'
   

   

5. Po zastosowaniu konfiguracji do urządzeń możesz sprawdzić, które bliźniacze reprezentacje urządzeń zostały zaktualizowane przy użyciu żądanej zawartości właściwości bliźniaczej reprezentacji (po stronie chmury), sprawdzając metryki Zastosowane (znane również jako appliedCount). Aby sprawdzić, które urządzenia pomyślnie zaktualizowały konfigurację, zobacz niestandardową metryki, która została utworzona powyżej.

   

Interfejs wiersza polecenia: określone urządzenie

1. Użyj następującego polecenia, aby utworzyć regułę, zastępując <identyfikator> urządzenia i/lub <nazwę> centrum w celu dopasowania do środowiska.

   az iot hub module-twin update -m osconfig --desired \
   '{
      "Firewall": {
         "desiredRules": [
            {
               "desiredState": "present",
               "action": "accept",
               "direction": "out",
               "protocol": "tcp",
               "destinationAddress": "10.9.9.0/24",
               "destinationPort": 443
            }
         ]
      }
   }' -d <device id> --hub-name <hub name>
   

2. Aby sprawdzić, czy konfiguracja została ukończona pomyślnie, zaczekaj co najmniej 30 sekund, a następnie przeczytaj bliźniaczy reprezentację modułu w następujący sposób:

   az iot hub query -q \
   "SELECT deviceId, properties.reported.Firewall.desiredRules.ac,properties.reported.Firewall.configurationStatus
   FROM devices.modules
   WHERE moduleId='osconfig'
   AND deviceId='<device id>'" --hub-name <hub name> --output table
   

   

Interfejs wiersza polecenia: na dużą skalę

1. Użyj następującego przykładowego polecenia, aby utworzyć konfigurację IoT Hub. Ta konfiguracja obejmuje kryteria określania wartości docelowych, żądaną konfigurację. Pamiętaj, aby zastąpić nazwę centrum nazwą IoT Hub. Należy pamiętać, że następujące czynności można wykonać w jednym poleceniu i bez używania plików tymczasowych, ale aby uniknąć złożonego polecenia monolitycznego z zagnieżdżonym znakiem ucieczki, wybieramy użycie sekwencji poleceń i dwóch plików tymczasowych. Ten format powinien być łatwiejszy do modyfikowania i dostosowywania do środowiska.

printf '
{
 "moduleContent": 
    {"properties.desired.Firewall":
       {"desiredRules": [
          {
             "desiredState": "present",
             "action": "accept",
             "direction": "out",
             "protocol": "tcp",
             "destinationAddress": "10.9.9.0/24",
             "destinationPort": 443
          }
       ]
    }
  }
 }' > temp_myconfig_modulecontent.json

 printf $' 
 { 
   "metrics": { 
      "queries": { 
         "successfullyconfigured": "SELECT deviceId FROM devices.modules WHERE moduleId=\'osconfig\' AND properties.reported.Firewall.desiredRules.ac=200 AND properties.reported.Firewall.  configurationStatus=\'success\'"
      }
   }
 }' > temp_myconfig_metrics.json  

 az iot hub configuration create -c "setfirewall_config" --content temp_myconfig_modulecontent.json \
 --target-condition "from devices.modules where moduleId='osconfig'" --priority 10 \
 --metrics temp_myconfig_metrics.json --hub-name <hub-name>

1. Aby sprawdzić, które bliźniacze reprezentacje urządzeń zostały zaktualizowane z zawartością żądanej właściwości bliźniaczej reprezentacji, zobacz metryka Zastosowana (znana również jako appliedCount). Należy pamiętać, że Zastosowane odzwierciedla tylko aktywność chmury ustawiania żądanych właściwości w bliźniaczych reprezentacjach. Aby sprawdzić, które urządzenia na świecie pomyślnie zaktualizowały konfigurację, zobacz niestandardową metryki, która została utworzona powyżej.

2. Użyj następujących poleceń, aby sprawdzić oba te metryki.

   az iot hub configuration show-metric --metric-id appliedCount \
   -c "setfirewall_config" --metric-type system \
   -n <hub name>
   
   az iot hub configuration show-metric --metric-id successfullyconfigured \
   -c "setfirewall_config" --metric-type user \
   -n <hub name> 
   

Przykład C. Porównanie odcisku palca stanu zapory wielu urządzeń ze znanym dobrym urządzeniem

Właściwość fingerprint umożliwia szybkie porównania sprawdzania zgodności na dużą skalę. Nie musisz pobierać wszystkich reguł ze wszystkich urządzeń, a następnie implementować strategię porównania wiele-do-wielu. Możesz po prostu sprawdzić, czy odcisk palca jest taki sam na różnych urządzeniach, które mają być zgodne ze sobą. Można na przykład porównać wdrożone urządzenia z znanym dobrym urządzeniem referencyjnym.

W przykładach pojedynczego urządzenia po prostu pobierzemy wartość, co oznacza, że wykonujesz porównanie poza pasmem. W przykładach na dużą skalę użyjemy operatora GROUP BY zapytania IoT Hub, aby pokazać powszechność lub rozbieżność w całej flocie.

Portal: określone urządzenie

Nie dotyczy, zobacz Witrynę Azure Portal na dużą skalę.

Portal: na dużą skalę

1. Na stronie portalu Azure IoT Hub wybierz pozycję Zarządzanie urządzeniami —>zapytania w obszarze nawigacji po lewej stronie.

2. Wykonaj następujące zapytanie:

   SELECT properties.reported.Firewall.fingerprint AS firewallFingerprint,
   COUNT() AS numberOfDevices
   FROM devices.modules
   GROUP BY properties.reported.Firewall.fingerprint
   

   

Interfejs wiersza polecenia: określone urządzenie

Nie dotyczy, zobacz "Bash / Cloud Shell, na dużą skalę"

Interfejs wiersza polecenia: na dużą skalę

1. Użyj następującego przykładowego polecenia, które porównuje fingerprint właściwość floty urządzeń, zastępując <identyfikator> urządzenia i/lub <nazwę> centrum w celu dopasowania do środowiska.

   az iot hub query -q \
   "SELECT properties.reported.Firewall.fingerprint AS firewallFingerprint,
   COUNT() AS numberOfDevices
   FROM devices.modules
   GROUP BY properties.reported.Firewall.fingerprint" \
   --hub-name <hub-name> --output table
   

   

Informacje referencyjne

Opis modelu obiektów

W tej sekcji opisano właściwości bliźniaczej reprezentacji i odpowiednie zachowania.

Porada

Dokumentacja referencyjna konfiguracji systemu operacyjnego dotyczy narzędzi z rozszerzonymi perspektywami modelu danych lub bez nich (Digital Twin Definition Language) (DTDL). Aby uzyskać więcej informacji, zobacz: Informacje o zwykłych żądanych/zgłoszonych widokach i rozszerzonych widokach DTDL.

Właściwości zgłaszane/tylko do odczytu zapory (w przypadku scenariuszy raportowania i inspekcji)

• Ścieżka: properties.reported.Firewall (Firewall składnik, właściwości tylko do odczytu)

• Opis: stan zapory hosta wykryty przez moduł zapory systemu operacyjnego

• Elementy członkowskie

  Nazwa	Typ	Uwagi
  configurationStatus	wyliczenie ciągów	Reprezentuje stan niepowodzenia/powodzenia osiągnięcia żądanej konfiguracji. Istotne tylko wtedy, gdy żądane właściwości konfiguracji, takie jak desiredRules lub desiredDefaultPolicies zostały ustawione. Możliwa wartość zapisu to success, failurei unknown.
  configurationStatusDetail	ciąg	Tekst zwracany przez bazowe interfejsy API lub narzędzia, takie jak iptables. Przeznaczony do zapewnienia pierwszego poziomu wglądu w złe parametry wejściowe itp. bez uciekania się do czesania dzienników diagnostycznych.
  defaultPolicies	tablica obiektów (zobacz przykładowy ładunek)	Reprezentuje domyślne przekazywanie pakietów przez zaporę, które nie spełniają żadnej określonej reguły. W kontekście obiektów iptable jest to mapowanie na zasady łańcucha dla łańcuchów wejściowych i wyjściowych tabeli filtrów. W innych aparatach zapory będzie to mapować zachowanie aparatu zapory zgodnie z potrzebami. Na przykład niektóre aparaty zapory nie mają jawnego pojęcia zasad i z natury upuść ruch, który nie spełnia żadnej reguły.
  linie papilarne	ciąg	• Nieprzezroczystych odcisków palców dla listy wszystkich reguł zapory na urządzeniu • Służy do porównywania dużej liczby urządzeń ze znanym dobrym urządzeniem UWAGA: W wersjach programu OSConfig przed wydaniem z października 2022 r. ta właściwość była znana jako "firewallFingerprint"
  stan	wyliczenie ciągów	Stan wysokiego poziomu zapory hosta. Możliwe wartości: • unknown • enabled • disabled Logika jest enabled taka, że wykryto aktywny aparat zapory i z co najmniej jedną regułą w tabeli FILTER. UWAGA: W wersjach programu OSConfig przed wydaniem z października 2022 r. te informacje zostały przedstawione jako "firewallState" (zamiast "state") i wartości były liczbami całkowitymi (a nie ciągami).

• Przykładowy ładunek (jak pokazano w sekcji bliźniaczej properties.reported reprezentacji)

  "Firewall": {
      "configurationStatus": "success",
      "configurationStatusDetail": "",
      "defaultPolicies": [
         {
            "direction": "in",
            "action": "accept"
         },
         {
            "direction": "out",
            "action": "accept"
         }
      ],
      "fingerprint": "c30d8b8bf5327a8a325a686e0c4bbf73b1bd33a72779af88827e8ea256caddb2",
      "state": "enabled"
  }
  

Żądana reguła zapory

Przestroga

Podobnie jak w przypadku administrowania zaporą, należy zachować szczególną ostrożność podczas blokowania ruchu. Możesz zablokować urządzeniu kontynuowanie połączenia z IoT Hub lub innymi kanałami administracyjnymi. W takich przypadkach może być konieczne odzyskanie dostępu lokalnego do urządzenia.

• Ścieżka: properties.desired.Firewall.desiredRules (Firewall składnik, desiredRules właściwość zapisywalna)

• Opis: uporządkowana lista deskryptorów reguł. Każdy deskryptor reguły na liście może mieć następujące elementy członkowskie.

• Elementy członkowskie każdego deskryptora reguł

  Nazwa	Typ	Uwagi
  desiredState	wyliczenie ciągów	Zawsze wymagane. Możliwe wartości to present (oznacza to, że taka reguła powinna zostać utworzona, jeśli reguła dopasowania nie istnieje) lub absent (oznacza to, że każda istniejąca reguła na urządzeniu pasującym do tego deskryptora powinna zostać usunięta, jeśli zostanie znaleziona. W przypadku deskryptorów reguł, gdzie desiredState: "present" i gdzie na urządzeniu nie istnieje już żadna zgodna reguła, nowa reguła jest dodawana w górnej części listy reguł na urządzeniu. W kontekście można o tym myśleć, że jest to analogiczne, a iptables -I nie iptables -A. Jeśli w systemie znajduje desiredRulessię wiele desiredState: "present" deskryptorów reguł, są one dodawane tak, aby kolejność została zachowana. Innymi słowy, aby wierzchołka reguły desiredRules znajduje się na początku listy reguł na urządzeniu, następna reguła w desiredRules pliku będzie przestrzegać tej reguły na liście reguł na urządzeniu itd.
  action	wyliczenie ciągów	Zawsze wymagane. Możliwe wartości to accept, droplub reject.
  kierunek	wyliczenie ciągów	Zawsze wymagane. Możliwe wartości to in lub out.
  Protokół	wyliczenie ciągów	Zawsze wymagane. Możliwe wartości to any, udp, tcplub icmp. Należy pamiętać, że any każdy ruch (w przeciwieństwie do znaczenia "tcp i udp, ale nie inne protokoły IP). W związku z tym reguły, w których protocol: "any" nie mogą zawierać sourcePort ani destinationPort.
  Sourceaddress	ciąg	Adres IP lub zakres CIDR. Jeśli nie zostanie określona, wynikowa reguła będzie zgodna z dowolnym adresem
  sourcePort	liczba całkowita	Dotyczy reguł, w których protocol: tcp lub protocol:udp. Nie może być uwzględniony w innych regułach. Określa numer portu, jeśli został uwzględniony w odpowiedniej regule. Jeśli nie zostanie uwzględniona, wskazuje regułę, która powinna być zgodna z dowolnym numerem portu.
  destinationAddress	ciąg	Adres IP lub zakres CIDR. Jeśli nie zostanie określona, wynikowa reguła będzie zgodna z dowolnym adresem
  destinationPort	liczba całkowita	Dotyczy reguł, w których protocol: tcp lub protocol:udp. Nie może być uwzględniony w innych regułach. Określa numer portu, jeśli został uwzględniony w odpowiedniej regule. Jeśli nie zostanie uwzględniona, wskazuje regułę, która powinna być zgodna z dowolnym numerem portu.

Przykładowy ładunek (jak pokazano w sekcji bliźniaczej properties.desired reprezentacji)

Następujące reguły reprezentują następujące intencje administratora:

1. "Moja podsieć administratora lokalnego to 10.9.9.0/24, więc chcę, aby urządzenia zezwalały na ruch przychodzący na porcie 22 (SSH) stamtąd"

2. "Moja stara podsieć administratora była 10.24.24.0/24, więc jeśli jakiekolwiek urządzenie nadal ma regułę zezwalającą na port 22 (SSH), chcę usunąć taką regułę"

3. UWAGA: Administrator może chcieć zablokować protokół SSH wszędzie (z powyższym wyjątkiem), ale w tym przykładzie użyjemy domyślnych zasad upuszczania, dzięki czemu taka reguła jest nadmiarowa. desiredDefaultPolicies Zobacz przykład w dalszej części tego dokumentu.

   "Firewall": {
      "desiredRules": [
         {
            "desiredState": "present",
            "action": "accept",
            "direction": "in",
            "protocol": "tcp",
            "sourceAddress": "10.9.9.0/24",
            "destinationPort": 22
         },
         {
            "desiredState": "absent",
            "action": "accept",
            "direction": "in",
            "protocol": "tcp",
            "sourceAddress": "10.24.24.0/24",
            "destinationPort": 22
         }
      ]
   }
   

Należy pamiętać, że gdy administracyjne przepływy pracy ustawiają properties.desired.Firewall.desiredRules (Firewall składnik, desiredRules właściwość zapisywalną z perspektywy JĘZYKA DTDL), urządzenie potwierdza otrzymanie tego samego wyniku, dodając desiredRules właściwość do properties.reported.Firewallklasy . Wartość tej właściwości zawiera kopię oryginalnego desiredRules ładunku wraz z numerem wersji i kodem stanu. IoT Hub oparte przepływy pracy administracyjne mogą użyć tej funkcji, aby określić, czy żądany stan został jeszcze osiągnięty na urządzeniu. Jest to tylko potwierdzenie. Aby określić, czy urządzenie zakończyło się powodzeniem w osiągnięciu żądanego stanu, zobacz configurationStatus również artykuły i configurationStatusDetail.

DesiredDefaultPolicies zapory

Przestroga

Podobnie jak w przypadku administrowania zaporą, należy zachować szczególną ostrożność podczas blokowania ruchu. Możesz zablokować urządzeniu kontynuowanie połączenia z IoT Hub lub innymi kanałami administracyjnymi. W takich przypadkach może być konieczne odzyskanie lokalnego dostępu do urządzenia.

Domyślne zasady wymagają szczególnie starannej aplikacji. Na przykład w systemach opartych na tabelach iptable zasady mają zastosowanie do każdego pakietu indywidualnie bez uwzględniania istniejących połączeń. Innymi słowy, domyślne zasady ruchu przychodzącego drop (oprócz blokowania nowych połączeń przychodzących) blokują odpowiedzi z systemów zdalnych. Może to uniemożliwić urządzeniu komunikację wychodzącą przy użyciu protokołów (takich jak TCP), które wymagają przepływu pakietów dwukierunkowych. Nie należy ustawiać drop wartości action na wartość w zasadach in lub out bez uprzedniego upewnienia się, że istnieją określone reguły, aby włączyć wszystkie wymagane pakiety w obu kierunkach.

• Ścieżka: properties.desired.Firewall.desiredDefaultPolicies (Firewall składnik, desiredDefaultPolicies właściwość zapisywalna)

• Opis: Tablica z dwoma elementami, opisując żądane domyślne zachowanie (akceptowanie lub upuszczanie) dla ruchu przychodzącego i dla ruchu wychodzącego.

• Elementy członkowskie każdego elementu

  Nazwa	Typ	Uwagi
  kierunek	wyliczenie ciągów	Możliwe wartości to in lub out
  action	wyliczenie ciągów	Zawsze wymagane. Możliwe wartości to accept lub drop.

Przykładowy ładunek (jak pokazano w sekcji bliźniaczej properties.desired reprezentacji)

"Firewall": {
   "desiredDefaultPolicies": [
      {"direction": "in", "action": "drop"},
      {"direction": "out", "action": "accept"}
   ]
}

Należy pamiętać, że gdy administracyjne przepływy pracy ustawiają properties.desired.Firewall.desiredDefaultPolicies (Firewall składnik, desiredDefaultPolicies właściwość zapisywalną z perspektywy JĘZYKA DTDL), urządzenie potwierdza otrzymanie tego samego wyniku, dodając desiredDefaultPolicies właściwość do properties.reported.Firewallklasy . Wartość tej właściwości zawiera kopię oryginalnego ładunku wraz z numerem wersji i kodem stanu. IoT Hub opartych na przepływach pracy administracyjnych może służyć do określenia, czy żądany stan został jeszcze osiągnięty na urządzeniu. Jest to tylko potwierdzenie odbioru i przetwarzania. Aby uzyskać więcej informacji na temat powodzenia lub niepowodzenia osiągnięcia żądanego stanu, zobacz configurationStatus i configurationStatusDetail.

Dodatkowe informacje i często zadawane pytania

A co z przypadkiem użycia "zastąp wszystko"?

W niektórych przypadkach administratorzy mogą chcieć narzucić absolutną kontrolę nad listą reguł zapory urządzenia. Wyobraź sobie intencję, taką jak "Powinny istnieć tylko reguły X, Y i Z; Wszelkie inne reguły (istniejące wcześniej na urządzeniu lub utworzone w czasie przez inne procesy) powinny być okresowo usuwane. Obecnie moduł zapory OSConfig nie zapewnia bezpośrednio tego przypadku użycia. Usunięcie określonych reguł można wykonać za pomocą desiredRules elementów i "desiredState": "absent", ale nie ma jawnej funkcji zastępowania wszystkich. Jeśli chcesz dodać taką funkcję, zapoznaj się z dokumentacją rozszerzalności w witrynie https://github.com/Azure/azure-osconfig.

Następne kroki

Aby zapoznać się z omówieniem scenariuszy i możliwości konfiguracji systemu operacyjnego, zobacz:

• Co to jest konfiguracja systemu operacyjnego dla IoT

Aby zapoznać się z konkretnymi praktycznymi przykładami, zobacz:

• Tworzenie środowiska laboratoryjnego OSConfig (za pomocą usługi Azure IoT) w ciągu 5 minut
• Szybki start: przykłady zapytań dotyczących rozpoczynania pracy z aplikacją OSConfig i usługą Azure IoT
• Co mogę aprowizować i zarządzać nimi?