Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом руководстве по устранению неполадок приведены инструкции по устранению большинства проблем пиринга между виртуальными сетями .
Настройка пиринга между двумя виртуальными сетями
Находятся ли виртуальные сети в одной подписке или в разных подписках?
Виртуальные сети находятся в одной подписке
Чтобы настроить пиринг виртуальных сетей для виртуальных сетей, которые находятся в одной подписке, используйте методы в следующих статьях:
- Если виртуальные сети находятся в одном регионе, см. статью «Создание пиринга».
- Если виртуальные сети находятся в разных регионах, см. пиринг между виртуальными сетями.
Примечание.
Подключение не работает через пиринг глобальной виртуальной сети для следующих ресурсов:
- Виртуальные машины (ВМ) за SKU базового внутреннего балансировщика нагрузки (ILB)
- Кэш Redis (использует SKU "Базовый" для внутренней балансировки нагрузки)
- Шлюз приложений версии 1 (использует SKU ILB уровня "Основной")
- Масштабируемые наборы виртуальных машин (используют SKU ILB уровня "Базовый")
- Кластеры Azure Service Fabric (используют базовый SKU ILB)
- SQL Server Always On (использует SKU "Базовый" внутренней подсистемы балансировки нагрузки)
- Среда службы приложений Azure для Power Apps (использует базовый ILB SKU)
- Управление API Azure (использует SKU ILB уровня "Базовый")
- Доменные службы Microsoft Entra (использует SKU SLB уровня "Базовый")
Дополнительные сведения см. в разделе о требованиях и ограничениях глобального пиринга.
Виртуальные сети находятся в разных подписках или клиентах Active Directory
Сведения о настройке пиринга виртуальных сетей для виртуальных сетей в разных подписках или клиентах Active Directory см. в статье "Создание пиринга между разными подписками".
Примечание.
Чтобы настроить пиринг сети, необходимо иметь разрешения участника сети в обеих подписках. Для получения дополнительной информации см. в разделе «Разрешения пиринга».
Настройка пиринга между виртуальными сетями с помощью топологии концентратора, которая использует локальные ресурсы
Для подключения типа "сеть — сеть" или подключения ExpressRoute
Выполните действия, описанные в разделе "Настройка транзита VPN-шлюза для пиринга виртуальной сети".
Для подключений типа "точка — сеть"
- Следуйте следующим шагам, как указано в разделе "Настройка транзита VPN-шлюза для пиринга виртуальной сети".
- После установки или изменения пиринга виртуальной сети скачайте и переустановите пакет "точка — сеть", чтобы клиенты типа "точка — сеть" получили обновленные маршруты в периферийную виртуальную сеть.
Настройка взаимодействия виртуальных сетей с использованием топологии "концентратор-спица"
Виртуальные сети находятся в одном регионе
- В центральной виртуальной сети настройте сетевое виртуальное устройство (NVA).
- В периферийных виртуальных сетях установлены маршруты, определяемые пользователем, использующие следующие переходы по типу "сетевое виртуальное устройство".
Дополнительные сведения см. в разделе "Цепочка служб".
Примечание.
Если вам нужна помощь по настройке NVA, обратитесь к поставщику NVA.
Сведения об устранении неполадок при настройке и маршрутизации устройств NVA см. в статье "Проблемы с виртуальным сетевым устройством" в Azure.
Виртуальные сети находятся в разных регионах
Теперь поддерживается транзит через глобальный пиринг виртуальных сетей. Подключение не работает через пиринг глобальной виртуальной сети для следующих ресурсов:
- Виртуальные машины, подключенные к внутреннему балансировщику нагрузки SKU "Базовый ILB"
- Кэш Redis (использует внутреннюю подсистему балансировки нагрузки со SKU "Базовый")
- шлюз приложений (использует SKU "Базовый" внутренний балансировщик нагрузки)
- Масштабируемые наборы (используют внутреннее SKU для ILB "Базовый");
- Кластеры Service Fabric (используют SKU "Базовый" внутреннего балансировщика нагрузки)
- группы доступности Always On для SQL Server (используют базовую SKU внутренней подсистемы балансировки нагрузки).
- Среда службы приложений (ASE), использующая базовый SKU для внутреннего балансировщика нагрузки.
- Управление API (использует внутренний балансировщик нагрузки SKU "Базовый")
- Доменные службы Microsoft Entra (использует SKU SLB уровня "Базовый")
Дополнительные сведения о требованиях и ограничениях глобального пиринга см. в статье об пиринге виртуальной сети.
Устранение неполадок с подключением между двумя одноранговыми виртуальными сетями
Войдите на портал Azure с учетной записью с необходимыми ролями и разрешениями. Выберите виртуальную сеть, выберите пиринг и проверьте поле "Состояние". Какой статус?
Состояние пиринга — "Подключен"
Чтобы устранить неполадку, выполните следующие действия.
Проверьте потоки сетевого трафика:
На исходной виртуальной машине используйте функции Устранение неполадок с подключением и Проверка IP-потока для целевой виртуальной машины, чтобы определить, нет ли NSG или UDR, вызывающих помехи в потоках трафика.
Если вы используете брандмауэр или NVA, выполните следующие действия.
- Задокументируйте параметры UDR, чтобы их можно было восстановить после выполнения этого шага.
- Удалите UDR из подсети исходной виртуальной машины или сетевую карту, которая указывает на NVA в качестве места назначения для следующего прыжка. Проверьте подключение от исходной виртуальной машины непосредственно к адресу назначения, минуя NVA. Если этот шаг не работает, см. средство устранения неполадок NVA.
Выполните трассировку сети.
Запустите трассировку сети на целевой виртуальной машине. Для Windows можно использовать Netsh. Для Linux используйте TCPDump.
Запустите TcpPing или PsPing из источника в целевой IP-адрес.
Это пример команды TcpPing :
tcping64.exe -t <destination VM address> 3389
После завершения TcpPing остановите трассировку сети в месте назначения.
Если пакеты поступают от исходной виртуальной машины, сетевая ошибка отсутствует. Изучите работу брандмауэра виртуальной машины и приложения, слушающего этот порт, для выявления проблемы конфигурации.
Примечание.
Вы не можете использовать глобальный пиринг между виртуальными сетями (виртуальным сетям в разных регионах) для подключения к ресурсам следующих типов:
- Виртуальные машины за внутренним балансировщиком нагрузки (ILB) SKU "Базовый"
- Кэш Redis (использует внутреннюю подсистему балансировки нагрузки с SKU "Базовый")
- шлюз приложений (использует SKU "Базовый" внутреннего балансировщика нагрузки)
- Масштабируемые наборы (использует внутренний балансировщик нагрузки со SKU "Базовый")
- Кластеры Service Fabric (используют SKU "Basic ILB")
- группы доступности Always On для SQL Server (использует базовый SKU внутренней балансировки нагрузки);
- Среда службы приложений (ASE) использует подсистему балансировки нагрузки с SKU 'Базовый' (ILB).
- Управление API (использует SKU "Базовый" с внутренним балансировщиком нагрузки)
- Доменные службы Microsoft Entra (использует SKU ILB уровня "Базовый")
Дополнительные сведения см. в разделе о глобальном пиринге — его требованиях и ограничениях.
Статус пиринга — "Отключено"
Чтобы устранить эту проблему, удалите пиринг из обеих виртуальных сетей, а затем повторно создайте их.
Устранение неполадок с подключением между периферийной виртуальной сетью концентратора и локальным ресурсом
Использует ли ваша сеть сторонний NVA или VPN-шлюз?
Моя сеть использует сторонний NVA или VPN-шлюз
Сведения об устранении неполадок с подключением, влияющих на сторонний NVA или VPN-шлюз, см. в следующих статьях:
Моя сеть не использует сторонний NVA или VPN-шлюз
У виртуальной сети концентратора и периферийной виртуальной сети есть VPN-шлюз?
Виртуальная сеть концентратора и периферийная виртуальная сеть имеют VPN-шлюз.
Использование удаленного шлюза не поддерживается.
Если у периферийной виртуальной сети уже есть VPN-шлюз, параметр Использовать удаленный шлюз не поддерживается в периферийной виртуальной сети. Это связано с ограничением пиринга между виртуальными сетями.
Виртуальная сеть концентратора и периферийная виртуальная сеть не имеют VPN-шлюза.
Для подключений типа "сеть — сеть" или Azure ExpressRoute проверьте следующие основные причины проблем с подключением к удаленной виртуальной сети из локальной среды:
- Убедитесь, что в виртуальной сети с шлюзом установлен флажок Разрешить перенаправленный трафик.
- Убедитесь, что в виртуальной сети без шлюза установлен флажок Использовать удаленный шлюз.
- Убедитесь, что администратор сети проверяет локальные устройства, чтобы убедиться, что все они добавлены в адресное пространство удаленной виртуальной сети.
Для подключений "точка — сеть" выполните следующие действия.
- Убедитесь, что в виртуальной сети с шлюзом установлен флажок Разрешить перенаправленный трафик.
- Убедитесь, что в виртуальной сети без шлюза установлен флажок Использовать удаленный шлюз.
- Скачайте и переустановите пакет клиента "точка — сеть". Новые маршруты виртуальных сетей, недавно подключенные по пирингу, не добавляются автоматически для клиентов по схеме «точка-сеть».
Устранение неполадок с сетевым подключением между периферийными виртуальными сетями в одном регионе
Сеть концентратора должна включать NVA. Настройте UDR в периферийных устройствах с NVA, заданными в качестве следующего прыжка, и включите переадресованный трафик в центральной виртуальной сети.
Дополнительные сведения см. в разделе "Цепочка служб" и обсуждение этих требований с выбранным поставщиком NVA .
Устранение неполадок с сетевым подключением между периферийными виртуальными сетями в разных регионах
Теперь поддерживается транзит через глобальный пиринг виртуальных сетей. Подключение не работает через пиринг глобальной виртуальной сети для следующих ресурсов:
- Виртуальные машины за базовым внутренним балансировщиком нагрузки SKU
- Кэш Redis (использует внутренний балансировщик нагрузки со SKU "Базовый")
- Шлюз приложений (использует внутренний балансировщик нагрузки со SKU "Базовый")
- Масштабируемые наборы (используют внутренний балансировщик нагрузки с SKU "Базовый").
- Кластеры Service Fabric (используют SKU «Базовый» внутреннего балансировщика нагрузки)
- Группы доступности SQL Server Always On (используют базовый SKU внутренней подсистемы балансировки нагрузки)
- Среда служб приложений (ASE) (использует схему внутренней балансировки нагрузки SKU "Базовый").
- Управление API (использует базовый тип внутреннего балансировщика нагрузки ILB)
- Доменные службы Microsoft Entra (использует SKU SLB уровня "Базовый")
Дополнительные сведения см. в требованиях и ограничениях глобального пиринга и различных топологий VPN.
Устранение неполадок с сетевым подключением между веб-приложением и виртуальной сетью типа "hub-and-spoke"
Чтобы устранить неполадку, выполните следующие действия.
- Войдите на портал Azure.
- В веб-приложении выберите сеть и выберите "Интеграция виртуальной сети".
- Проверьте, можно ли просмотреть удаленную виртуальную сеть. Вручную введите адресное пространство удаленной виртуальной сети (синхронизация сети и добавление маршрутов).
Дополнительные сведения см. в следующих статьях:
- Интегрируйте ваше приложение в виртуальную сеть Azure
- Сведения о маршрутизации VPN-подключений "точка — сеть"
Устранение неполадок конфигурации пиринга виртуальной сети, вызвавшей сообщение об ошибке
Текущий клиент <TENANT ID>
не авторизован для доступа к связанной подписке
Чтобы устранить эту проблему, см. статью "Создание пиринга виртуальной сети между различными подписками".
Не подключено
Чтобы устранить эту проблему, удалите пиринг из обеих виртуальных сетей и повторно создайте их.
Не удалось выполнить пиринг виртуальной сети Databricks
Чтобы устранить эту проблему, настройте пиринг виртуальной сети в Azure Databricks, а затем укажите целевую виртуальную сеть с помощью идентификатора ресурса. Для получения дополнительной информации см. справочник "Настройка пиринга виртуальной сети Databricks с удаленной виртуальной сетью".
Удаленная виртуальная сеть не имеет шлюза
Эта проблема возникает при объединении виртуальных сетей от разных арендаторов и последующей настройке Use Remote Gateways
. Ограничение портала Azure заключается в том, что он не может проверить наличие шлюза виртуальной сети в виртуальной сети другого клиента.
Эту проблему можно решить двумя способами.
- Удалите пиринги и активируйте
Use Remote Gateways
параметр при создании нового пиринга. - Используйте PowerShell или CLI вместо портала Azure, чтобы включить
Use Remote Gateways
.