Устранение сбоев сеанса Бастион Azure из-за неработоспособности целевых виртуальных машин

Сводка

В этой статье приводятся пошаговые инструкции по диагностике и устранению сбоев сеансов Бастион Azure, вызванных проблемами на целевой виртуальной машине. Рассматриваются распространенные основные причины, такие как остановленные или деаллоцированные виртуальные машины, блокировка брандмауэром гостевой ОС, сбои служб протокола удаленного рабочего стола (RDP) или SSH, неисправные агенты виртуальных машин и неправильная настройка проверки подлинности на уровне сети (NLA).

Бастион Azure сбои сеанса часто возникают из-за проблем на целевой виртуальной машине, а не самого узла Бастион Azure. Самые распространенные из них:

• Виртуальная машина остановлена или высвобождена.
• Служба RDP (Windows) или управляющая программа SSH (Linux) не запущена.
• Брандмауэр гостевой ОС блокирует порт 3389 или 22.
• Правило группы безопасности сети (NSG) блокирует подключение между Бастион Azure и виртуальной машиной.
• Агент виртуальной машины работает некорректно.
• NLA неправильно настроена на Windows.

Симптомы

Вы можете столкнуться с одним или несколькими из следующих симптомов:

• Сеанс Бастион Azure на портале Azure завершается ошибкой подключения или временем ожидания.
• На портале показано, как не удается подключиться к виртуальной машине при подключении через Бастион Azure.
• Узел Бастион Azure развернут и отображается со статусом Успешно, но подключения к определенной виртуальной машине не удаются.
• Попытки подключения перестают отвечать и в конечном итоге истекает время ожидания.
• Сеанс RDP или SSH подключается через Бастион Azure но немедленно отключается.
• Бастион Azure работает с другими виртуальными машинами в той же виртуальной сети (VNet), но не работает с одной конкретной виртуальной машиной.

Prerequisites

• Необходимые разрешения:Reader разрешения на группу ресурсов узла Бастион Azure и Virtual Machine Contributor разрешения для целевой группы ресурсов виртуальной машины (для runCommand и start операций).
• Средства: Azure CLI 2.x или агент ИИ с доступом Azure CLI.
• Обязательные переменные и примеры этих переменных, как показано в следующей таблице:

СОВЕТ: Каждый скрипт, предоставленный в следующих разделах, запрашивает необходимые значения в интерактивном режиме. Чтобы открыть Cloud Shell и ответить на запросы, нажмите кнопку "Попробовать". Значения кэшируются для этого сеанса. Поэтому вы вводите их только один раз.

Этапы диагностики

Шаг 1

Проверьте, развернут ли узел Бастион Azure и работоспособен ли он. Если Бастион Azure не находится в работоспособном состоянии, проблема на стороне Бастион Azure, и это руководство неприменимо.

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:        " SUBSCRIPTION
[ -z "$BASTION_RG" ] && read -rp "Bastion Resource Group:  " BASTION_RG
[ -z "$BASTION_NAME" ] && read -rp "Bastion Host Name:      " BASTION_NAME

az network bastion show \
  --name "$BASTION_NAME" \
  --resource-group "$BASTION_RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{name:name, provisioningState:provisioningState, sku:sku.name}" \
  --output table

Интерпретация результатов

Шаг 2

Проверьте, работает ли целевая виртуальная машина и является ли агент виртуальной машины работоспособным. Остановленная или освобожденная виртуальная машина не может принимать Бастион Azure подключения. Агент неработоспособной виртуальной машины предотвращает выполнение удаленной команды, необходимой для диагностики гостевой ОС в последующих шагах.

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm get-instance-view \
  --name "$VM_NAME" \
  --resource-group "$VM_RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{powerState:statuses[?starts_with(code,'PowerState/')].displayStatus|[0], agentStatus:vmAgent.statuses[0].displayStatus, agentVersion:vmAgent.vmAgentVersion}" \
  --output table

Интерпретация результатов

Шаг 3

Проверьте тип ОС виртуальной машины (Windows или Linux) и его основной идентификатор сетевого интерфейса. Тип ОС определяет, какая гостевая диагностика будет выполняться позже. Идентификатор сетевого адаптера необходим для проверки NSG на шаге 4.

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm show \
  --name "$VM_NAME" \
  --resource-group "$VM_RG" \
  --subscription "$SUBSCRIPTION" \
  --query "{osType:storageProfile.osDisk.osType, nicId:networkProfile.networkInterfaces[0].id}" \
  --output json

Интерпретация результатов

Запишите оба значения по мере их необходимости в последующих шагах:

Шаг 4

Проверьте, не блокируют ли правила NSG на сетевом интерфейсе виртуальной машины или в её подсети входящий трафик из подсети Бастион Azure на порту подключения (3389 для Windows и RDP, 22 для Linux и SSH). Бастион Azure подключается к виртуальной машине по её частному IP-адресу из сети AzureBastionSubnet.

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

# Get the VM's primary NIC ID
NIC_ID=$(az vm show \
  --name "$VM_NAME" \
  --resource-group "$VM_RG" \
  --subscription "$SUBSCRIPTION" \
  --query "networkProfile.networkInterfaces[0].id" \
  --output tsv)

# Get NIC-level NSG (if any)
NIC_NSG=$(az network nic show --ids "$NIC_ID" \
  --query "networkSecurityGroup.id" --output tsv 2>/dev/null)

# Get subnet ID and subnet-level NSG (if any)
SUBNET_ID=$(az network nic show --ids "$NIC_ID" \
  --query "ipConfigurations[0].subnet.id" --output tsv)
SUBNET_NSG=$(az network vnet subnet show --ids "$SUBNET_ID" \
  --query "networkSecurityGroup.id" --output tsv 2>/dev/null)

echo "NIC NSG:    ${NIC_NSG:-None}"
echo "Subnet NSG: ${SUBNET_NSG:-None}"

# Show inbound rules for each NSG
for NSG_ID in $NIC_NSG $SUBNET_NSG; do
  if [ -n "$NSG_ID" ] && [ "$NSG_ID" != "None" ]; then
    echo ""
    echo "=== NSG: $(basename $NSG_ID) ==="
    az network nsg show --ids "$NSG_ID" \
      --query "securityRules[?direction=='Inbound'].{Name:name, Priority:priority, Access:access, Source:sourceAddressPrefix, DestPort:destinationPortRange}" \
      --output table
  fi
done

if [ -z "$NIC_NSG" ] && [ -z "$SUBNET_NSG" ]; then
  echo "No NSG is applied to the VM NIC or subnet — network traffic is not filtered."
fi

Интерпретация результатов

Просмотрите выходные данные для правил, влияющих на порт 3389 (Windows и RDP) или 22 (Linux и SSH). Правила NSG оцениваются в порядке приоритета. Сначала обрабатывается наименьший номер приоритета.

Шаг 5a

Проверьте работоспособность гостевой ОС Windows, в том числе:

• Запущена ли служба RDP (TermService).
• Включена ли RDP в реестре.
• Разрешает ли брандмауэр Windows подключения RDP.
• Совместимость параметров NLA с Бастион Azure.
• Имеет ли диск ОС свободное место.

Для этого шага требуется здоровый агент виртуальной машины (подтвержден на шаге 2).

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunPowerShellScript \
  --scripts \
    'Write-Output "=== RDP Service (TermService) ==="' \
    '$svc = Get-Service TermService -ErrorAction SilentlyContinue' \
    'if ($svc) { Write-Output "Status: $($svc.Status)" } else { Write-Output "Status: NOT FOUND" }' \
    'Write-Output ""' \
    'Write-Output "=== RDP Enabled ==="' \
    '$deny = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -ErrorAction SilentlyContinue).fDenyTSConnections' \
    'Write-Output "fDenyTSConnections: $deny (0=enabled, 1=disabled)"' \
    'Write-Output ""' \
    'Write-Output "=== Windows Firewall - RDP Inbound Rules ==="' \
    'Get-NetFirewallRule -DisplayGroup "Remote Desktop" -ErrorAction SilentlyContinue | Where-Object { $_.Direction -eq "Inbound" } | Select-Object DisplayName, Enabled, Action | Format-Table -AutoSize | Out-String' \
    'Write-Output "=== NLA Setting ==="' \
    '$nla = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -ErrorAction SilentlyContinue).UserAuthentication' \
    'Write-Output "UserAuthentication: $nla (1=NLA required, 0=NLA not required)"' \
    'Write-Output ""' \
    'Write-Output "=== OS Disk Free Space ==="' \
    'Get-PSDrive C -ErrorAction SilentlyContinue | Select-Object @{N="FreeGB";E={[math]::Round($_.Free/1GB,2)}} | Format-Table -AutoSize | Out-String' \
  --query "value[0].message" \
  --output tsv

Интерпретация результатов

Шаг 5b

Проверьте состояние гостевой ОС Linux, в том числе:

• Запущен ли демон SSH.
• Порт 22 прослушивает.
• Правила брандмауэра на уровне узла (iptables и firewalld) разрешают подключения SSH.

Для этого шага требуется здоровый агент виртуальной машины (подтвержден на шаге 2).

Выполните следующие команды в Azure CLI:

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunShellScript \
  --scripts \
    'echo "=== SSH Daemon Status ==="' \
    'systemctl is-active sshd 2>/dev/null || systemctl is-active ssh 2>/dev/null || echo "INACTIVE"' \
    'echo ""' \
    'echo "=== SSH Port Listening ==="' \
    'ss -tlnp 2>/dev/null | grep -E ":22\b" || echo "Nothing listening on port 22"' \
    'echo ""' \
    'echo "=== iptables Rules (INPUT chain) ==="' \
    'iptables -L INPUT -n --line-numbers 2>/dev/null | head -20 || echo "iptables not available"' \
    'echo ""' \
    'echo "=== firewalld Status ==="' \
    'if systemctl is-active firewalld >/dev/null 2>&1; then firewall-cmd --list-services 2>/dev/null; else echo "firewalld not active"; fi' \
    'echo ""' \
    'echo "=== OS Disk Free Space ==="' \
    'df -h / 2>/dev/null | tail -1' \
  --query "value[0].message" \
  --output tsv

Интерпретация результатов

Используйте следующую таблицу карты принятия решений, чтобы определить соответствующие действия на основе результатов диагностики.

Разрешение A

Целевая виртуальная машина остановлена или деаллоцирована. Виртуальная машина должна находиться в состоянии питания Running, чтобы принимать подключения через Бастион Azure.

Выполните следующие команды в Azure CLI.

1. Запустите виртуальную машину.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm start \
  --name "$VM_NAME" \
  --resource-group "$VM_RG" \
  --subscription "$SUBSCRIPTION"

1. Подождите 1–2 минуты, пока виртуальная машина завершит загрузку, а затем повторно запустите шаг 2. Состояние питания должно отображаться VM running.

Повторите попытку подключения Бастион Azure. Если проблема не устранена, перейдите к шагу 3, чтобы проверить состояние гостевой ОС.

Разрешение B

Правило NSG сетевого адаптера или подсети виртуальной машины блокирует входящий трафик через порт 3389 (RDP) или 22 (SSH) из подсети Бастион Azure.

Выполните следующие команды в Azure CLI.

1. Определите правило блокировки из выходных данных шага 4 . Обратите внимание на имя NSG, имя правила и приоритет правила.
2. Добавьте правило разрешения для подключения Бастион Azure-to-VM. Задайте для приоритета число меньше, чем правило запрета блокировки, поэтому сначала оно вычисляется.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:             " SUBSCRIPTION
[ -z "$NSG_RG" ] && read -rp "NSG Resource Group:          " NSG_RG
[ -z "$NSG_NAME" ] && read -rp "NSG Name (from Step 4):      " NSG_NAME
[ -z "$BASTION_SUBNET_CIDR" ] && read -rp "Bastion Subnet CIDR:         " BASTION_SUBNET_CIDR
[ -z "$CONNECTION_PORT" ] && read -rp "Connection Port (3389 or 22): " CONNECTION_PORT

az network nsg rule create \
  --nsg-name "$NSG_NAME" \
  --resource-group "$NSG_RG" \
  --subscription "$SUBSCRIPTION" \
  --name Allow-Bastion-Inbound \
  --priority 100 \
  --direction Inbound \
  --source-address-prefix "$BASTION_SUBNET_CIDR" \
  --destination-port-range "$CONNECTION_PORT" \
  --protocol Tcp \
  --access Allow

Измените значение --priority , если 100 конфликтует с существующим правилом. Значение должно быть ниже приоритета правила блокировки Deny .

3. Повторно выполните шаг 4. Новое разрешающее правило имеет более низкий приоритет, чем правило Deny.

Повторите попытку подключения Бастион Azure.

Резолюция C

Служба RDP (Windows) или управляющая программа SSH (Linux) на целевой виртуальной машине не запущена или не прослушивает ожидаемый порт.

Выполните следующие команды в Azure CLI.

1. Для Windows включите RDP и перезапустите TermService.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunPowerShellScript \
  --scripts \
    'Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0' \
    'Set-Service TermService -StartupType Automatic' \
    'Start-Service TermService' \
    'Write-Output "TermService status: $((Get-Service TermService).Status)"' \
  --query "value[0].message" \
  --output tsv

2. В Linux включите и перезапустите демон SSH.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunShellScript \
  --scripts \
    'systemctl enable sshd 2>/dev/null || systemctl enable ssh 2>/dev/null' \
    'systemctl restart sshd 2>/dev/null || systemctl restart ssh 2>/dev/null' \
    'echo "sshd status: $(systemctl is-active sshd 2>/dev/null || systemctl is-active ssh 2>/dev/null)"' \
  --query "value[0].message" \
  --output tsv

3. Повторно запустите шаг 5a для Windows или шага 5b для Linux, чтобы убедиться, что служба запущена и прослушивается.

Повторите попытку подключения Бастион Azure.

Разрешение D

Брандмауэр гостевой ОС (Брандмауэр Windows, iptables или firewalld) блокирует входящие подключения на порт RDP или SSH.

Выполните следующие команды в Azure CLI.

1. Для Windows включите правила брандмауэра RDP.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunPowerShellScript \
  --scripts \
    'Enable-NetFirewallRule -DisplayGroup "Remote Desktop"' \
    'Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Where-Object { $_.Direction -eq "Inbound" } | Select-Object DisplayName, Enabled, Action | Format-Table -AutoSize | Out-String' \
  --query "value[0].message" \
  --output tsv

2. Для Linux разрешите SSH через iptables или firewalld.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunShellScript \
  --scripts \
    'if systemctl is-active firewalld >/dev/null 2>&1; then' \
    '  firewall-cmd --permanent --add-service=ssh' \
    '  firewall-cmd --reload' \
    '  echo "firewalld: SSH service added"' \
    'else' \
    '  iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT' \
    '  echo "iptables: SSH allow rule added"' \
    'fi' \
    'ss -tlnp | grep ":22" || echo "Port 22 still not listening — check sshd"' \
  --query "value[0].message" \
  --output tsv

3. Повторно запустите шаг 5a (Windows) или шаг 5b (Linux), чтобы подтвердить, что брандмауэр теперь разрешает подключение.

Повторите попытку подключения Бастион Azure.

Разрешение E

Агент виртуальной машины (waagent в Linux, WindowsAzureGuestAgent в Windows) неисправен или не отвечает. Без исправного агента Azure не сможет выполнять команды на виртуальной машине, а некоторые сценарии подключения через Бастион Azure могут быть нарушены.

Выполните следующие команды в Azure CLI.

1. Перезапустите виртуальную машину, чтобы попытаться восстановить работу агента.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm restart \
  --name "$VM_NAME" \
  --resource-group "$VM_RG" \
  --subscription "$SUBSCRIPTION"

2. Подождите 2–3 минуты, а затем повторно запустите шаг 2. Если agentStatus отображается Ready, перейдите к шагу 3 , чтобы продолжить диагностику.

Если агент остается неработоспособным после перезапуска, см. статью "Устранение неполадок с агентом виртуальной машины Azure Windows" для действий по восстановлению вручную.

Разрешение F

NLA включена на виртуальной машине Windows и отклоняет подключение Бастион Azure. Бастион Azure SKU Standard поддерживает NLA, однако несовпадение параметров Credential Security Support Provider (CredSSP) или протокола Transport Layer Security (TLS) может приводить к ошибкам согласования NLA, которые выглядят как немедленный разрыв сеанса.

Выполните следующие команды в Azure CLI.

1. Временно отключите NLA, чтобы проверить, является ли это причиной.

# ── Collect inputs (cached if already set in this session) ──
[ -z "$SUBSCRIPTION" ] && read -rp "Subscription ID:    " SUBSCRIPTION
[ -z "$VM_RG" ] && read -rp "VM Resource Group:  " VM_RG
[ -z "$VM_NAME" ] && read -rp "VM Name:            " VM_NAME

az vm run-command invoke \
  --resource-group "$VM_RG" \
  --name "$VM_NAME" \
  --subscription "$SUBSCRIPTION" \
  --command-id RunPowerShellScript \
  --scripts \
    'Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication -Value 0' \
    '$nla = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").UserAuthentication' \
    'Write-Output "NLA disabled. UserAuthentication is now: $nla"' \
  --query "value[0].message" \
  --output tsv

2. Повторите попытку подключения Бастион Azure. Если теперь всё работает, причиной была NLA.

Чтобы повторно включить NLA после подтверждения подключения, изучите параметры CredSSP и TLS на виртуальной машине или убедитесь, что номер SKU Бастион Azure является стандартным (который имеет более широкую совместимость NLA). Дополнительные сведения см. в разделе Бастион Azure и NLA.

References

• Бастион Azure часто задаваемые вопросы
• Устранение неполадок Бастион Azure
• Доступ к NSG и Бастион Azure
• Устранение неполадок агента виртуальной машины Azure Windows
• Сброс учетных данных виртуальной машины с помощью Azure CLI
• Устранение неполадок Windows виртуальной машины путем подключения диска ОС к виртуальной машине восстановления
• Устранение неполадок виртуальной машины Linux путем подключения диска ОС к виртуальной машине восстановления