Zdiagnozuj problem filtra ruchu sieciowego maszyny wirtualnej

Z tego artykułu dowiesz się, jak zdiagnozować problemy z filtrowaniem ruchu sieciowego dla maszyny wirtualnej. Proces obejmuje wyświetlanie obowiązujących reguł zabezpieczeń stosowanych przez sieciową grupę zabezpieczeń.

Grupy zabezpieczeń (NSG) umożliwiają kontrolowanie typów ruchu, który przepływa do i z maszyny wirtualnej (VM). Możesz powiązać NSG z podsiecią w wirtualnej sieci Azure, interfejsem sieciowym podłączonym do maszyny wirtualnej lub z oboma tymi elementami. Skuteczne zasady bezpieczeństwa stosowane do interfejsu sieciowego są agregacją zasad, które istnieją w NSG powiązanym z interfejsem sieciowym oraz podsiecią, w której znajduje się interfejs sieciowy. Reguły w różnych sieciowych grupach zabezpieczeń mogą czasami powodować konflikt ze sobą i wpływać na łączność sieciową maszyny wirtualnej. Możesz wyświetlić wszystkie skuteczne zasady zabezpieczeń z NSG zastosowane na interfejsach sieciowych Twojej maszyny wirtualnej. Jeśli nie jesteś zaznajomiony z pojęciami wirtualnej sieci, interfejsu sieciowego lub grup zabezpieczeń sieci, zapoznaj się z omówieniem wirtualnej sieci, interfejsem sieciowym, i omówieniem grup zabezpieczeń sieci.

Scenario

Próbujesz połączyć się z maszyną wirtualną przez port 80 z internetu, ale połączenie się nie udaje. Aby określić, dlaczego nie można uzyskać dostępu do portu 80 z Internetu, możesz wyświetlić obowiązujące reguły zabezpieczeń interfejsu sieciowego przy użyciu Azure portal, PowerShell lub Azure CLI.

Kolejne kroki zakładają, że masz istniejącą maszynę wirtualną, dla której chcesz zobaczyć skuteczne zasady bezpieczeństwa. Jeśli nie masz istniejącej maszyny wirtualnej, najpierw wdroż maszynę wirtualną Linux lub Windows, aby wykonać zadania opisane w tym artykule. Przykłady w tym artykule dotyczą maszyny wirtualnej o nazwie myVM z interfejsem sieciowym o nazwie myVMVMNic. Maszyna wirtualna i interfejs sieciowy są w grupie zasobów o nazwie myResourceGroup, i znajdują się w regionie East US. Zmień wartości w krokach odpowiednio dla maszyny wirtualnej, dla której diagnozujesz problem.

Diagnozowanie przy użyciu portalu Azure

  1. Zaloguj się do Azure portal przy użyciu konta Azure z uprawnieniami necessary.

  2. Na górze portalu Azure wpisz nazwę maszyny wirtualnej w polu wyszukiwania. Gdy nazwa maszyny wirtualnej pojawi się w wynikach wyszukiwania, wybierz ją.

  3. Rozwiń Sieć w lewym okienku. Wybierz pozycję Ustawienia sieciowe. Na poniższych ilustracjach przedstawiono ustawienia sieciowej grupy zabezpieczeń dla interfejsu sieciowego maszyny wirtualnej.

    Zrzut ekranu przedstawiający reguły zabezpieczeń dla NSG nsg-subnet.

    Zrzut ekranu przedstawiający reguły zabezpieczeń dla sieciowej grupy zabezpieczeń sieciowej grupy zabezpieczeń.

    Reguły widoczne na poprzedniej ilustracji dotyczą interfejsu sieciowego o nazwie vm-1445. Zobaczysz, że istnieją reguły portów przychodzących dla interfejsu sieciowego z dwóch różnych sieciowych grup zabezpieczeń:

    • nsg-subnet: skojarzone z podsiecią, w którą znajduje się interfejs sieciowy.
    • nsg-nic: skojarzone z interfejsem sieciowym na maszynie wirtualnej o nazwie vm-1445.

    Reguła o nazwie DenyAllInBound to właśnie ta zapobiega komunikacji przychodzącej do maszyny wirtualnej przez port 80 z internetu, jak opisano w scenariuszu. Reguła wymienia 0.0.0.0/0 dla ŹRÓDŁO, co obejmuje internet. Żadna inna reguła o niższym priorytecie (niższym numerze) nie zezwala na ruch przychodzący do portu 80. Aby zezwolić na przychodzące połączenia na porcie 80 do maszyny wirtualnej z internetu, zobacz Rozwiązywanie problemu. Aby dowiedzieć się więcej o zasadach bezpieczeństwa i sposobie ich stosowania przez Azure, zobacz Grupy zabezpieczeń sieci.

    W dolnej części obrazu zobaczysz również reguły portów wychodzących. Zostaną wyświetlone reguły portów wychodzących dla interfejsu sieciowego.

    Chociaż obraz przedstawia tylko cztery reguły ruchu przychodzącego dla każdej sieciowej grupy zabezpieczeń, sieciowe grupy zabezpieczeń mogą mieć o wiele więcej niż cztery reguły. Na ilustracji widzisz VirtualNetwork pod Źródło i Miejsce docelowe oraz AzureLoadBalancer pod ŹRÓDŁO. VirtualNetwork i AzureLoadBalancer to tagi usługi. Tagi usługi reprezentują grupę prefiksów adresów IP, aby zminimalizować złożoność tworzenia reguł zabezpieczeń.

  4. Aby wyświetlić obowiązujące reguły zabezpieczeń, wybierz interfejs w ustawieniach sieci maszyny wirtualnej. Przed kontynuowaniem upewnij się, że maszyna wirtualna jest w stanie uruchomienia.

  5. W ustawieniach interfejsu sieciowego rozwiń Pomoc, a następnie wybierz Efektywne zasady bezpieczeństwa.

    Poniższy przykład przedstawia przykładowy interfejs sieciowy vm-1445 z wybranymi skutecznymi regułami zabezpieczeń .

    Zrzut ekranu przedstawiający obowiązujące reguły zabezpieczeń dla interfejsu sieciowego vm-1445.

    Zasady wymienione są takie same jak te, które widziałaś w kroku 3, chociaż są różne karty dla NSG powiązanego z interfejsem sieciowym i podsiecią. Jak widać na zdjęciu, pokazane są tylko pierwsze 50 reguł. Aby pobrać plik .csv zawierający wszystkie zasady, wybierz Pobierz.

  6. Poprzednie kroki pokazały reguły zabezpieczeń interfejsu sieciowego o nazwie vm-1445. Co zrobić, jeśli maszyna wirtualna ma dwa interfejsy sieciowe? W tym przykładzie maszyna wirtualna ma dołączone dwie karty sieciowe. Skuteczne zasady zabezpieczeń mogą się różnić dla każdego interfejsu sieciowego.

    Aby wyświetlić reguły interfejsu sieciowego vm-nic-2 , wybierz je. Jak pokazano w poniższym przykładzie, interfejs sieciowy ma te same reguły skojarzone z podsiecią co interfejs sieciowy vm-1445 , ponieważ oba interfejsy sieciowe znajdują się w tej samej podsieci. Po powiązaniu NSG z podsiecią, jego reguły są stosowane do wszystkich interfejsów sieciowych w tej podsieci.

    Zrzut ekranu przedstawiający reguły zabezpieczeń dla karty sieciowej vm-nic-2.

    W przeciwieństwie do interfejsu sieciowego vm-1445 interfejs sieciowy vm-nic-2 nie ma skojarzonej sieciowej grupy zabezpieczeń. Każdy interfejs sieciowy i podsieć może mieć zerowe lub jedno NSG przypisane do niego. NSG powiązane z każdą kartą sieciową lub podsiecią mogą być takie same lub różne. Możesz powiązać tę samą grupę zabezpieczeń sieci z tyloma interfejsami sieciowymi i podsieciami, ile wybierzesz.

Proponowane poprawki: Chociaż skuteczne zasady bezpieczeństwa były widoczne w VM, możesz również zobaczyć skuteczne zasady bezpieczeństwa poprzez jednostkę:

Diagnozowanie za pomocą PowerShell

Notatka

Zalecamy użycie modułu Azure Az PowerShell do interakcji z Azure. Aby rozpocząć, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się, jak migrować do modułu Az PowerShell, zobacz Migracja Azure PowerShell z AzureRM do Az.

Możesz uruchomić poniższe polecenia w Azure Cloud Shell lub korzystając z PowerShell na swoim komputerze. Azure Cloud Shell to darmowa interaktywna powłoka. Ma zainstalowane i skonfigurowane popularne narzędzia Azure do użycia z Twoim kontem. Jeśli uruchamiasz PowerShell ze swojego komputera, potrzebujesz modułu Azure PowerShell w wersji 1.0.0 lub nowszej. Uruchom Get-Module -ListAvailable Az na swoim komputerze, aby znaleźć zainstalowaną wersję. Jeśli potrzebujesz aktualizacji, zobacz Install Azure PowerShell module. Jeśli korzystasz z programu PowerShell lokalnie, musisz również uruchomić polecenie Connect-AzAccount , aby zalogować się do platformy Azure przy użyciu konta z wymaganymi uprawnieniami].

Uzyskaj skuteczne zasady bezpieczeństwa dla interfejsu sieciowego dzięki Get-AzEffectiveNetworkSecurityGroup. Poniższy przykład pobiera obowiązujące reguły zabezpieczeń dla interfejsu sieciowego o nazwie vm-nic , który znajduje się w grupie zasobów o nazwie test-rg:

$Params = @{
  NetworkInterfaceName = "vm-nic"
  ResourceGroupName    = "test-rg"
}
Get-AzEffectiveNetworkSecurityGroup @Params

Wynik jest zwracany w formacie JSON. Aby zrozumieć dane wyjściowe, zobacz interpretację danych wyjściowych polecenia. Wynik jest zwracany tylko wówczas, gdy NSG jest powiązany z interfejsem sieciowym, podsiecią, w której znajduje się interfejs sieciowy, lub oboma. Maszyna wirtualna musi być w stanie uruchomienia. Maszyna wirtualna może mieć wiele interfejsów sieciowych z zastosowaniem różnych sieciowych grup zabezpieczeń. Podczas rozwiązywania problemów, uruchom polecenie dla każdego interfejsu sieciowego.

Jeśli nadal masz problem z łącznością, zobacz więcej diagnoz i zagadnień.

Jeśli znasz tylko nazwę maszyny wirtualnej, użyj następujących poleceń, aby wyświetlić listę wszystkich identyfikatorów interfejsów sieciowych dołączonych do maszyny wirtualnej.

$Params = @{
  Name              = "vm-1"
  ResourceGroupName = "test-rg"
}
$VM = Get-AzVM @Params
$VM.NetworkProfile

Otrzymasz dane wyjściowe podobne do następującego przykładu:

NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/vm-nic

W poprzednich danych wyjściowych nazwa interfejsu sieciowego to vm-nic.

Diagnozowanie za pomocą Azure CLI

Jeśli używasz poleceń Azure CLI do wykonywania zadań opisanych w tym artykule, uruchom polecenia w Azure Cloud Shell lub przez uruchomienie Azure CLI z komputera. Ten artykuł wymaga wersji Azure CLI 2.0.32 lub nowszej. Uruchom az --version, aby znaleźć zainstalowaną wersję. Jeśli musisz zainstalować lub uaktualnić, zobacz Install Azure CLI. Jeśli uruchamiasz narzędzie Azure CLI lokalnie, musisz również uruchomić az login i zalogować się do Azure za pomocą konta, które ma niezbędne uprawnienia.

Uzyskaj skuteczne zasady bezpieczeństwa dla interfejsu sieciowego za pomocą az network nic list-effective-nsg. Poniższy przykład pobiera obowiązujące reguły zabezpieczeń dla interfejsu sieciowego o nazwie vm-nic , który znajduje się w grupie zasobów o nazwie test-rg:

az network nic list-effective-nsg \
  --name vm-nic \
  --resource-group test-rg

Wynik jest zwracany w formacie JSON. Aby zrozumieć dane wyjściowe, zobacz interpretacja danych wyjściowych polecenia. Wynik jest zwracany tylko wówczas, gdy NSG jest powiązany z interfejsem sieciowym, podsiecią, w której znajduje się interfejs sieciowy, lub oboma. Maszyna wirtualna musi być w stanie uruchomienia. Maszyna wirtualna może mieć wiele interfejsów sieciowych z zastosowaniem różnych sieciowych grup zabezpieczeń. Podczas rozwiązywania problemów, uruchom polecenie dla każdego interfejsu sieciowego.

Jeśli nadal masz problem z łącznością, zobacz więcej diagnoz i zagadnień.

Jeśli znasz tylko nazwę maszyny wirtualnej, użyj następujących poleceń, aby wyświetlić listę wszystkich identyfikatorów interfejsów sieciowych dołączonych do maszyny wirtualnej.

az vm show \
  --name vm-1 \
  --resource-group test-rg

W zwróconych danych wyjściowych zobaczysz informacje podobne do następującego przykładu:

"networkProfile": {
    "additionalProperties": {},
    "networkInterfaces": [
      {
        "additionalProperties": {},
        "id": "/subscriptions/<ID>/resourceGroups/test-rg/providers/Microsoft.Network/networkInterfaces/vm-nic",
        "primary": true,
        "resourceGroup": "test-rg"
      },

W poprzednich danych wyjściowych nazwa interfejsu sieciowego to vm-nic

Interpretowanie danych wyjściowych polecenia

Niezależnie od tego, czy użyto PowerShell, czy Azure CLI w celu zdiagnozowania problemu, otrzymujesz dane wyjściowe zawierające następujące informacje:

  • NetworkSecurityGroup: Identyfikator grupy zabezpieczeń sieci.
  • Association: wskazuje, czy sieciowa grupa zabezpieczeń jest powiązana z interfejsem sieciowym lub podsiecią. Jeśli stan skojarzenia sieciowej grupy zabezpieczeń zmieni się tuż przed uruchomieniem polecenia, poczekaj kilka sekund, aby wynik odzwierciedlił aktualizację.
  • EffectiveSecurityRules: Objaśnienie każdej właściwości jest szczegółowo opisane w Tworzenie reguły bezpieczeństwa. Nazwy reguł poprzedzone defaultSecurityRules/ to domyślne reguły bezpieczeństwa istniejące w każdej NSG. Nazwy reguł poprzedzone regułami zabezpieczeńRules/ są regułami utworzonymi przez użytkownika. Reguły określające tag usługi, takie jak Internet, VirtualNetwork i AzureLoadBalancer dla właściwości destinationAddressPrefix lub sourceAddressPrefix , również mają wartości dla właściwości expandedDestinationAddressPrefix . Właściwość expandedDestinationAddressPrefix wymienia wszystkie prefiksy adresowe reprezentowane przez tag usługi.

Zduplikowane reguły pojawiają się w danych wyjściowych, gdy NSG jest powiązane zarówno z interfejsem sieciowym, jak i podsiecią. Reguły domyślne i wszystkie reguły niestandardowe współużytkowane przez NSG (sieciowe grupy zabezpieczeń) powodują duplikaty.

Reguła o nazwie defaultSecurityRules/DenyAllInBound to właśnie ta zapobiega komunikacji przychodzącej do maszyny wirtualnej przez port 80 z internetu, jak opisano w scenariuszu. Żadna inna reguła o wyższym priorytecie (niższym numerze) nie zezwala na dopuszczenie portu 80 z internetu.

Rozwiąż problem

Problem opisany w scenariuszu można zdiagnozować przy użyciu witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure. Rozwiązaniem jest utworzenie reguły zabezpieczeń sieci z następującymi właściwościami:

Własność Wartość
Źródło Any
Zakresy portów źródłowych Any
Destination Adres IP maszyny wirtualnej, zakres adresów IP lub wszystkie adresy w podsieci.
Zakresy portów docelowych 80
Protokół TCP
Akcja Allow
Priorytet 100
Name Allow-HTTP-All

Po utworzeniu reguły port 80 jest dozwolony dla ruchu przychodzącego z Internetu, ponieważ jego priorytet jest wyższy niż domyślna reguła DenyAllInBound . Jeśli sieciowe grupy zabezpieczeń są skojarzone z interfejsem sieciowym i podsiecią, utwórz tę samą regułę w obu sieciowych grupach zabezpieczeń. Dowiedz się, jak stworzyć regułę bezpieczeństwa.

Scenariusze zarządzania Windows wymagające RPC/DCOM

Windows Management Instrumentation (WMI) oraz Distributed Component Object Model (DCOM) wykorzystują zdalne wywołanie procedur (RPC). Klient najpierw łączy się z RPC Endpoint Mapper na porcie TCP 135. Maper punktów końcowych kieruje następnie klienta do dynamicznie przydzielonego portu TCP. Przy bieżących ustawieniach domyślnych systemu Windows zakres dynamicznego TCP wynosi 49152-65535. Przed utworzeniem reguły zweryfikuj skonfigurowany zakres na docelowej maszynie wirtualnej z systemem Windows; jeśli host używa spersonalizowanego zakresu, użyj tego zweryfikowanego zakresu zamiast zakładać 49152-65535.

Dla każdego NSG powiązanego z podsiecią lub interfejsem sieciowym docelowej maszyny wirtualnej należy utworzyć obie reguły zezwalające na ruch przychodzący. Zastąp <target-vm-nic-or-subnet-prefix> zatwierdzoną siecią zarządzania, hostem lub usługą, a <management-source-prefix> zastąp docelową maszyną wirtualną, kartą sieciową lub miejscem docelowym podsieci. Zastąp <priority-rpc-endpoint-mapper> i <priority-rpc-dynamic> na różne nieużywane priorytety będące liczbami całkowitymi między 100 a 4096. Obie reguły są wymagane, ponieważ test tylko TCP 135 może się powiedzieć, podczas gdy kolejne dynamiczne połączenie RPC jest zablokowane.

Więcej informacji o tym przepływie WMI/DCOM można znaleźć w artykule Troubleshoot NSG misconfigurations that block traffic in Azure Virtual Network. Szczegóły dotyczące portów systemu Windows i RPC można znaleźć w artykule Przegląd usług i wymagania portów sieciowych, Rozwiązywanie problemów z połączeniem zdalnym WMI oraz Dynamiczne porty RPC a zapory.

az network nsg rule create \
  --resource-group <resource-group> \
  --nsg-name <nsg-name> \
  --name Allow-RpcEndpointMapper \
  --priority <priority-rpc-endpoint-mapper> \
  --source-address-prefixes <management-source-prefix> \
  --source-port-ranges '*' \
  --destination-address-prefixes <target-vm-nic-or-subnet-prefix> \
  --destination-port-ranges 135 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound

az network nsg rule create \
  --resource-group <resource-group> \
  --nsg-name <nsg-name> \
  --name Allow-RpcDynamic \
  --priority <priority-rpc-dynamic> \
  --source-address-prefixes <management-source-prefix> \
  --source-port-ranges '*' \
  --destination-address-prefixes <target-vm-nic-or-subnet-prefix> \
  --destination-port-ranges 49152-65535 \
  --access Allow \
  --protocol Tcp \
  --direction Inbound

Wartość 49152-65535 w regule dynamicznej jest tylko domyślna. Jeśli zweryfikowałeś niestandardowy zakres na docelowej maszynie wirtualnej z systemem Windows, zamień go w tej zasadzie.

$managementSourcePrefix = "<management-source-prefix>"
$targetDestinationPrefix = "<target-vm-nic-or-subnet-prefix>"
$rpcEndpointMapperPriority = 300
$rpcDynamicPriority = 310

$networkSecurityGroup = Get-AzNetworkSecurityGroup `
  -Name "<nsg-name>" `
  -ResourceGroupName "<resource-group>"

Add-AzNetworkSecurityRuleConfig `
  -Name "Allow-RpcEndpointMapper" `
  -Description "Allow RPC Endpoint Mapper from approved management source" `
  -NetworkSecurityGroup $networkSecurityGroup `
  -Access Allow `
  -Protocol Tcp `
  -Direction Inbound `
  -Priority $rpcEndpointMapperPriority `
  -SourceAddressPrefix $managementSourcePrefix `
  -SourcePortRange "*" `
  -DestinationAddressPrefix $targetDestinationPrefix `
  -DestinationPortRange "135"

Add-AzNetworkSecurityRuleConfig `
  -Name "Allow-RpcDynamic" `
  -Description "Allow RPC dynamic ports from approved management source" `
  -NetworkSecurityGroup $networkSecurityGroup `
  -Access Allow `
  -Protocol Tcp `
  -Direction Inbound `
  -Priority $rpcDynamicPriority `
  -SourceAddressPrefix $managementSourcePrefix `
  -SourcePortRange "*" `
  -DestinationAddressPrefix $targetDestinationPrefix `
  -DestinationPortRange "49152-65535"

Set-AzNetworkSecurityGroup -NetworkSecurityGroup $networkSecurityGroup

Gdy platforma Azure przetwarza ruch przychodzący, przetwarza reguły w sieciowej grupie zabezpieczeń skojarzonej z podsiecią (jeśli istnieje skojarzona sieciowa grupa zabezpieczeń), a następnie przetwarza reguły w sieciowej grupie zabezpieczeń skojarzonej z interfejsem sieciowym. Jeśli istnieje sieciowa grupa zabezpieczeń skojarzona z interfejsem sieciowym i podsiecią, port musi być otwarty w obu sieciowych grupach zabezpieczeń, aby ruch dotarł do maszyny wirtualnej. Aby ułatwić zarządzanie i rozwiązywanie problemów z komunikacją, zalecamy przypisanie NSG do podsieci, zamiast do indywidualnych interfejsów sieciowych. Jeśli maszyny wirtualne w podsieci wymagają różnych reguł zabezpieczeń, możesz przypisać interfejsy sieciowe do grupy zabezpieczeń aplikacji (ASG) i określić grupę ASG jako źródło i miejsce docelowe dla reguły zabezpieczeń. Dowiedz się więcej o grupach zabezpieczeń aplikacji.

Jeśli nadal występują problemy z komunikacją, zobacz Zagadnienia i więcej diagnostyki.

Rozważania

Rozważ następujące kwestie podczas rozwiązywania problemów z łącznością.

  • Domyślne zasady bezpieczeństwa blokują dostęp przychodzący z internetu i zezwalają tylko na ruch przychodzący z wirtualnej sieci. Aby umożliwić ruch przychodzący z Internetu, dodaj reguły zabezpieczeń o wyższym priorytecie niż domyślne reguły. Dowiedz się więcej o domyślnych regułach bezpieczeństwa lub jak dodać regułę bezpieczeństwa.

  • W przypadku równorzędnych sieci wirtualnych domyślnie tag usługi VIRTUAL_NETWORK automatycznie rozwija się w celu uwzględnienia prefiksów dla równorzędnych sieci wirtualnych. Aby rozwiązać wszelkie problemy związane z peeringiem sieci wirtualnej, możesz zobaczyć prefiksy na liście ExpandedAddressPrefix . Dowiedz się więcej o krotnym połączeniu sieci wirtualnych i tagach usług.

  • Platforma Azure pokazuje obowiązujące reguły zabezpieczeń dla interfejsu sieciowego tylko wtedy, gdy sieciowa grupa zabezpieczeń jest powiązana z interfejsem sieciowym maszyny wirtualnej lub jej podsiecią. Ponadto maszyna wirtualna musi być w stanie uruchomienia.

  • Jeśli interfejs sieciowy lub podsieć nie ma skojarzonej sieciowej grupy zabezpieczeń, wszystkie porty pozostają otwarte dla dostępu przychodzącego i wychodzącego, gdy maszyna wirtualna ma publiczny adres IP. Ta konfiguracja umożliwia nieograniczony dostęp do i z dowolnego miejsca. Aby zabezpieczyć maszynę wirtualną, zastosuj sieciową grupę zabezpieczeń do podsieci obsługującej interfejs sieciowy, jeśli ma publiczny adres IP.

Więcej diagnoz

  • Aby szybko przetestować, czy ruch jest dozwolony do lub z maszyny wirtualnej, użyj funkcji IP flow verify dostępnej w Azure Network Watcher. Komenda "IP flow verify" informuje, czy ruch jest dozwolony, czy zablokowany. Jeśli zostanie odrzucony, IP flow verify powie ci, która reguła bezpieczeństwa blokuje ruch.
  • Jeśli nie ma reguł zabezpieczeń powodujących niepowodzenie łączności sieciowej maszyny wirtualnej, problem może być spowodowany:
    • Oprogramowanie zapory działające w systemie operacyjnym maszyny wirtualnej
    • Trasy skonfigurowane dla wirtualnych urządzeń lub ruchu lokalnego. Ruch internetowy może być przekierowywany do Twojej lokalnej sieci za pomocą wymuszonego tunelowania. W przypadku wymuszenia tunelowania ruchu internetowego do urządzenia wirtualnego lub lokalnego może nie być możliwe nawiązanie połączenia z maszyną wirtualną z Internetu. Aby dowiedzieć się, jak diagnozować problemy z trasą, które mogą utrudniać przepływ ruchu z maszyny wirtualnej, zobacz Diagnozowanie problemu z routingiem ruchu sieciowego maszyny wirtualnej.

Następne kroki