Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: IoT Edge 1.5
Внимание
IoT Edge 1.5 LTS является поддерживаемым выпуском. IoT Edge 1.4 LTS заканчивается жизнью с 12 ноября 2024 года. Если вы используете более ранний выпуск, см. статью Обновление IoT Edge.
Если в среде возникают проблемы с сетью с помощью Azure IoT Edge для Linux (EFLOW), воспользуйтесь этой статьей в качестве руководства по устранению неполадок и диагностика. Кроме того, ознакомьтесь со справкой по устранению неполадок с виртуальными машинами EFLOW для IoT Edge для Linux на устройстве Windows.
Изоляция проблемы
При устранении неполадок IoT Edge для Linux в сети Windows существует четыре сетевых компонента, которые могут вызывать проблемы:
- Конфигурация IP-адресов
- Конфигурация системы доменных имен (DNS)
- Конфигурации брандмауэра и портов
- Другие компоненты
Дополнительные сведения о сетевых концепциях EFLOW см. в разделе IoT Edge для Linux в сети Windows. Кроме того, дополнительные сведения о конфигурациях сети EFLOW см. в разделе "Конфигурация сети" для Azure IoT Edge для Linux в Windows.
Проверка IP-адресов
Первым шагом при устранении неполадок IoT Edge для Linux в сети Windows должно быть проверка конфигураций IP-адресов виртуальной машины. Если IP-связь неправильно настроена, все входящие и исходящие подключения завершаются ошибкой.
- Запустите сеанс PowerShell с повышенными привилегиями с помощью запуска от имени администратора.
- Проверьте IP-адрес, возвращенный агентом жизненного цикла виртуальной машины. Запишите IP-адрес и сравните его с тем, который получен из виртуальной машины в последующих шагах.
Get-EflowVmAddr
- Подключитесь к виртуальной машине EFLOW.
Connect-EflowVm
- Проверьте конфигурацию сетевого интерфейса виртуальной машины eth0 .
В выходных данных вы увидите сведения о конфигурации eth0 . Убедитесь, что адрес inet задан правильно.ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.31.100.171 netmask 255.255.240.0 broadcast 172.31.111.255 inet6 fe80::215:5dff:fe2a:2f62 prefixlen 64 scopeid 0x20<link> ether 00:15:5d:2a:2f:62 txqueuelen 1000 (Ethernet) RX packets 115746 bytes 11579209 (11.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 976 bytes 154184 (150.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Если IP-адрес inet пуст или отличается от предоставленного с помощью командлетаGet-EflowVmAddr
, необходимо устранить неполадки, почему виртуальная машина EFLOW имеет недопустимый или не назначенный IP-адрес. Чтобы устранить проблему, используйте следующую таблицу:
Виртуальный коммутатор | Назначение IP-адресов | Устранение неполадок |
---|---|---|
Внешняя. | Статический IP-адрес | Убедитесь, что ip-конфигурация настроена правильно. Следует использовать все три параметра ip4Address, ip4GateWayAddress и ip4PrefixLength. IP-адрес, назначенный виртуальной машине, должен быть допустимым и не используется другим устройством во внешней сети. Конфигурации интерфейса виртуальной машины EFLOW можно проверить, проверив файлы в разделе /etc/systemd/network/ . |
Внешняя. | DHCP | Убедитесь, что в внешней сети есть DHCP-сервер. Если DHCP-сервер недоступен, используйте статические IP-конфигурации. Кроме того, убедитесь, что DHCP-сервер не имеет политики брандмауэра в отношении MAC-адресов. Если он имеется, вы можете получить MAC-адрес EFLOW с помощью командлета Get-EflowVmAddr . |
Переключатель по умолчанию | DHCP | Как правило, проблема связана с неисправностью коммутатора по умолчанию. Попробуйте перезагрузить ос узла Windows. Если проблема сохранится, попробуйте отключить и включить Hyper-V |
Внутренняя | Статический IP-адрес | Убедитесь, что ip-конфигурация настроена правильно. Следует использовать все три параметра ip4Address, ip4GateWayAddress и ip4PrefixLength. IP-адрес, назначенный виртуальной машине, должен быть допустимым и не используется другим устройством во внутренней сети. Кроме того, чтобы подключиться к Интернету, необходимо настроить таблицу NAT. Выполните действия по настройке NAT в Azure IoT Edge для Linux на виртуальном коммутаторе Windows. |
Внутренняя | DHCP | Убедитесь, что в внутренней сети есть DHCP-сервер. Чтобы настроить DHCP-сервер и таблицу NAT в Windows Server, выполните действия, описанные в статье о создании виртуального коммутатора Windows в Azure IoT Edge для Linux. Если DHCP-сервер недоступен, используйте статические IP-конфигурации. |
Предупреждение
В некоторых случаях при использовании внешнего виртуального коммутатора на виртуальной машине Windows Server или клиента может потребоваться дополнительная конфигурация. Дополнительные сведения о вложенных конфигурациях виртуализации см. в разделе "Вложенная виртуализация" для Azure IoT Edge для Linux в Windows.
Если у вас по-прежнему возникают проблемы с назначением IP-адреса, попробуйте настроить другую виртуальную машину Windows или Linux и назначить тот же коммутатор и IP-конфигурацию. Если у вас есть та же проблема с новой виртуальной машиной, отличной от EFLOW, проблема, скорее всего, связана с виртуальным коммутатором или IP-конфигурацией, и она не относится к EFLOW.
Проверка конфигурации системы доменных имен (DNS)
На втором шаге при устранении неполадок IoT Edge для Linux в сети Windows необходимо проверить DNS-серверы, назначенные виртуальной машине EFLOW. Чтобы проверить конфигурацию DNS виртуальной машины EFLOW, см . сведения о конфигурации сети для Azure IoT Edge для Linux в Windows. Если решение адресов работает, проблема, скорее всего, связана с конфигурациями брандмауэра или безопасности в сети.
Виртуальная машина EFLOW использует системную службу, разрешаемую системой, для управления разрешением DNS. Дополнительные сведения об этой службе см. в разделе Systemd-resolved. Чтобы настроить определенный DNS-адрес, можно использовать Set-EflowVmDnsServers
командлет. Если вам нужны дополнительные сведения о конфигурации DNS, можно проверить /etc/systemd/resolved.conf и службу, разрешаемуюsudo systemctl status systemd-resolved
системой, с помощью команды. Кроме того, можно задать определенный DNS-сервер в рамках конфигурации модуля, см . вариант 2. Установка DNS-сервера в развертывании IoT Edge на модуль.
Разрешение адресов может завершиться сбоем по нескольким причинам. Во-первых, DNS-серверы можно настроить правильно, однако их нельзя достичь из виртуальной машины EFLOW. Если DNS-серверы отвечают на трафик связи ICMP, можно попробовать проверить сетевое подключение к DNS-серверам.
- Запустите сеанс PowerShell с повышенными привилегиями с помощью запуска от имени администратора.
- Подключитесь к виртуальной машине EFLOW.
Connect-EflowVm
- Проверка адреса DNS-сервера и проверка ответа.
ping <DNS-Server-IP-Address>
Совет
Если сервер доступен, вы должны получить ответ, и проблема может быть связана с другими конфигурациями DNS-сервера. Если нет ответа, возможно, у вас возникла проблема с подключением к серверу.
Во-вторых, некоторые сетевые среды ограничивают доступ DNS-серверов к определенным адресам списка разрешений. Если это так, сначала убедитесь, что dns-сервер можно получить из операционной системы узла Windows, а затем обратитесь к группе сети, если необходимо добавить IP-адрес EFLOW в список разрешений.
Наконец, некоторые сетевые среды блокируют общедоступные DNS-серверы, такие как Google DNS (8.8.8 и 8.8.4.4). В этом случае обратитесь к группе сетевой среды, чтобы определить действительный DNS-сервер, а затем настроить его с помощью командлета Set-EflowVmDnsServers
.
Проверьте правила конфигурации брандмауэра и портов
Azure IoT Edge для Linux в Windows разрешает обмен данными с локального сервера в облако Azure с помощью поддерживаемых протоколов Центр Интернета вещей Azure. Дополнительные сведения о протоколах Центр Интернета вещей см. в разделе о выборе протокола связи. Дополнительные сведения о Центр Интернета вещей конфигурациях брандмауэра и портов см. в статье "Устранение неполадок устройства IoT Edge".
IoT Edge для Linux в Windows по-прежнему зависит от базовой ОС узла Windows и конфигурации сети. Поэтому необходимо обеспечить правильную настройку правил сети и брандмауэра для безопасного пограничного взаимодействия с облаком. Следующая таблица может использоваться в качестве руководства при размещении правил брандмауэра конфигурации для базовых серверов, на которых размещается Azure IoT Edge для Linux в среде выполнения Windows:
Протокол | Порт | Входящие | Исходящий | Руководство |
---|---|---|---|---|
MQTT | 8883 | ЗАБЛОКИРОВАННЫЕ (по умолчанию) | ЗАБЛОКИРОВАННЫЕ (по умолчанию) | Настройте исходящую (исходящую) функцию Open при использовании MQTT в качестве протокола связи. 1883 для MQTT не поддерживается IoT Edge. — Входящие (входящие) подключения должны быть заблокированы. |
AMQP | 5671 | ЗАБЛОКИРОВАННЫЕ (по умолчанию) | ОТКРЫТЫЕ (по умолчанию) | Протокол связи по умолчанию для IoT Edge. Необходимо настроить для открытия , если Azure IoT Edge не настроен для других поддерживаемых протоколов или AMQP является требуемым протоколом связи. 5672 для AMQP не поддерживается IoT Edge. Заблокируйте этот порт, если Azure IoT Edge использует другой протокол, поддерживаемый Центром Интернета вещей. Входящие подключения должны быть заблокированы. |
HTTPS | 443 | ЗАБЛОКИРОВАННЫЕ (по умолчанию) | ОТКРЫТЫЕ (по умолчанию) | Настройте исходящую (исходящую) функцию "Открыть " через порт 443 для подготовки IoT Edge. Эта конфигурация необходима при использовании созданных вручную сценариев или Службы подготовки устройств к добавлению в Центр Интернета вещей Azure. Входящее (входящее) подключение должно быть открыто только для двух конкретных сценариев: 1. Если у вас есть прозрачный шлюз с подчиненными устройствами, которые могут отправлять запросы методов. В этом случае порт 443 не должен быть открыт для внешних сетей для подключения к Центр Интернета вещей или предоставления служб Центр Интернета вещей через Azure IoT Edge. Таким образом, входящее правило может быть ограничено только открытием входящих (входящих) из внутренней сети. 2. Для сценариев клиента к устройству (C2D). 80 для HTTP не поддерживается IoT Edge. Если протоколы, отличные от HTTP (например, AMQP или MQTT), не могут быть настроены в организации; Сообщения можно отправлять через WebSockets. Порт 443 используется для связи WebSocket в этом случае. |
Примечание.
Если вы используете внешний виртуальный коммутатор, обязательно добавьте соответствующие правила брандмауэра для сопоставлений портов модуля, которые вы используете в виртуальной машине EFLOW.
Дополнительные сведения о брандмауэре виртуальной машины EFLOW см. в статье IoT Edge для Linux на Безопасность Windows. Чтобы проверить правила виртуальной машины EFLOW, выполните следующие действия.
- Запустите сеанс PowerShell с повышенными привилегиями с помощью запуска от имени администратора.
- Подключитесь к виртуальной машине EFLOW.
Connect-EflowVm
-
Список правил брандмауэра iptables.
sudo iptables -L
Чтобы добавить правило брандмауэра к виртуальной машине EFLOW, можно использовать примеры командлетов PowerShell EFLOW Util . Кроме того, вы можете создать те же правила, выполнив следующие действия.
- Запустите сеанс PowerShell с повышенными привилегиями с помощью запуска от имени администратора.
- Подключение к виртуальной машине EFLOW
Connect-EflowVm
- Добавьте правило брандмауэра для приема входящего трафика через <порт> протокола> (udp или tcp).<
sudo iptables -A INPUT -p <protocol> --dport <port> -j ACCEPT
- Наконец, сохраните правила, чтобы они были повторно созданы при каждой загрузке виртуальной машины.
sudo iptables-save | sudo tee /etc/systemd/scripts/ip4save
Проверка других конфигураций
Существует несколько других причин, по которым сетевое взаимодействие может завершиться ошибкой. В следующем разделе приводится лишь несколько проблем, с которыми пользователи столкнулись в прошлом.
Виртуальная машина EFLOW не отвечает на запросы проверки связи (ТРАФИК ICMP).
По умолчанию ответ на трафик ICMP отключен в брандмауэре виртуальной машины EFLOW. Чтобы ответить на запросы связи, разрешите трафик ICMP с помощью следующего командлета PowerShell:
Invoke-EflowVmCommand "sudo iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT"
Сбой обнаружения устройств с использованием многоадресного трафика.
Во-первых, чтобы разрешить обнаружение устройств с помощью многоадресной рассылки, виртуальная машина Hyper-V должна быть настроена для использования внешнего коммутатора. Во-вторых, настраиваемый модуль IoT Edge должен быть настроен для использования сети узла с помощью параметров создания контейнера:
{ "HostConfig": { "NetworkMode": "host" }, "NetworkingConfig": { "EndpointsConfig": { "host": {} } } }
Добавлены правила брандмауэра, но трафик по-прежнему недоступен для модуля IoT Edge.
Если связь по-прежнему не работает после добавления соответствующих правил брандмауэра, попробуйте полностью отключить брандмауэр для устранения неполадок.
sudo iptables -F sudo iptables -X sudo iptables -P INPUT ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables -P FORWARD ACCEPT
После завершения перезагрузите виртуальную машину (
Stop-EflowVm
иStart-EflowVm
), чтобы вернуть брандмауэр виртуальной машины EFLOW в нормальное состояние.Не удается подключиться к Интернету при использовании нескольких сетевых адаптеров.
Как правило, эта проблема связана с проблемой маршрутизации. Узнайте , как настроить Конфигурацию Azure IoT Edge для Linux в Windows Industrial IoT и DMZ , чтобы настроить статический маршрут.
Следующие шаги
Считаете, что обнаружили ошибку в платформе IoT Edge? Отправьте запрос, чтобы мы как можно скорее устранили неисправность.
Если у вас есть другие вопросы, создайте запрос в службу поддержки для получения справки.