Diagnozowanie problemu z routingiem sieciowym maszyny wirtualnej przy użyciu interfejsu wiersza polecenia platformy Azure

Artykuł
10/30/2024

Z tego artykułu dowiesz się, jak za pomocą narzędzia do następnego przeskoku usługi Azure Network Watcher rozwiązywać i diagnozować problem z routingiem maszyn wirtualnych, który uniemożliwia mu prawidłową komunikację z innymi zasobami.

Wymagania wstępne

Konto platformy Azure z aktywną subskrypcją. Utwórz konto bezpłatnie.
Azure Cloud Shell lub interfejs wiersza polecenia platformy Azure.

Kroki opisane w tym artykule umożliwiają interaktywne uruchamianie poleceń interfejsu wiersza polecenia platformy Azure w usłudze Azure Cloud Shell. Aby uruchomić polecenia w usłudze Cloud Shell, wybierz pozycję Otwórz usługę Cloud Shell w prawym górnym rogu bloku kodu. Wybierz pozycję Kopiuj , aby skopiować kod i wklej go w usłudze Cloud Shell, aby go uruchomić. Możesz również uruchomić usługę Cloud Shell z poziomu witryny Azure Portal.

Możesz również zainstalować interfejs wiersza polecenia platformy Azure lokalnie , aby uruchomić polecenia. Ten artykuł wymaga interfejsu wiersza polecenia platformy Azure w wersji 2.0 lub nowszej. Uruchom polecenie az --version , aby znaleźć zainstalowaną wersję. Jeśli uruchomisz interfejs wiersza polecenia platformy Azure lokalnie, zaloguj się do platformy Azure przy użyciu polecenia az login .

Tworzenie maszyny wirtualnej

Przed utworzeniem maszyny wirtualnej musisz utworzyć grupę zasobów, która będzie zawierała maszynę wirtualną. Utwórz grupę zasobów za pomocą polecenia az group create. W poniższym przykładzie pokazano tworzenie grupy zasobów o nazwie myResourceGroup w lokalizacji eastus:

az group create --name myResourceGroup --location eastus

Utwórz maszynę wirtualną za pomocą polecenia az vm create. Jeśli klucze SSH nie istnieją jeszcze w domyślnej lokalizacji kluczy, to polecenie je utworzy. Aby użyć określonego zestawu kluczy, użyj opcji --ssh-key-value. W poniższym przykładzie utworzono maszynę wirtualną o nazwie myVM:

az vm create \
  --resource-group myResourceGroup \
  --name myVm \
  --image Ubuntu2204 \
  --generate-ssh-keys

W ciągu kilku minut zostanie utworzona maszyna wirtualna. Nie wykonuj pozostałych kroków, dopóki maszyna wirtualna nie zostanie utworzona, a interfejs wiersza polecenia platformy Azure zwróci dane wyjściowe.

Testowanie komunikacji sieciowej

Aby przetestować komunikację sieciową z usługą Network Watcher, należy najpierw włączyć usługę Network Watcher w regionie, w którym ma być testowa maszyna wirtualna, a następnie użyć funkcji następnego przeskoku usługi Network Watcher w celu przetestowania komunikacji.

Włączanie usługi Network Watcher

Jeśli masz już włączoną usługę Network Watcher w regionie Wschodnie stany USA, przejdź do sekcji Użyj następnego przeskoku. Użyj polecenia az network watcher configure, aby utworzyć usługę Network Watcher w regionie Wschodnie stany USA:

az network watcher configure \
  --resource-group NetworkWatcherRG \
  --locations eastus \
  --enabled

Korzystanie z funkcji Następny przeskok

Na platformie Azure są automatycznie tworzone trasy do domyślnych miejsc docelowych. Możesz tworzyć trasy niestandardowe zastępujące domyślne trasy. Czasami użycie tras niestandardowych może spowodować niepowodzenie komunikacji. Aby przetestować routing z maszyny wirtualnej, użyj polecenia az network watcher show-next-hop, aby określić następny przeskok routingu, gdy ruch jest przeznaczony dla określonego adresu.

Przetestuj komunikację wychodzącą z maszyny wirtualnej do jednego z adresów IP dla www.bing.com:

az network watcher show-next-hop \
  --dest-ip 13.107.21.200 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

Po kilku sekundach dane wyjściowe informują o tym, że następny typHopType to Internet i że routeTableId jest trasą systemową. Ten wynik informuje o tym, że istnieje prawidłowa trasa do miejsca docelowego.

Przetestuj komunikację wychodzącą z maszyny wirtualnej do adresu 172.31.0.100:

az network watcher show-next-hop \
  --dest-ip 172.31.0.100 \
  --resource-group myResourceGroup \
  --source-ip 10.0.0.4 \
  --vm myVm \
  --nic myVmVMNic \
  --out table

Zwrócone dane wyjściowe informują o tym, że parametr None jest nextHopType i że routeTableId jest również trasą systemową. Ten wynik oznacza, że istnieje prawidłowa trasa systemowa do miejsca docelowego, ale nie ma następnego przeskoku umożliwiającego kierowanie ruchu do miejsca docelowego.

Wyświetlanie szczegółów trasy

Aby dokładniej przeanalizować routing, przejrzyj obowiązujące trasy dla interfejsu sieciowego za pomocą polecenia az network nic show-effective-route-table :

az network nic show-effective-route-table \
  --resource-group myResourceGroup \
  --name myVmVMNic

W zwracanych danych wyjściowych znajduje się następujący tekst:

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
  },
  "addressPrefix": [
    "0.0.0.0/0"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "Internet",
  "source": "Default",
  "state": "Active"
},

Gdy użyto az network watcher show-next-hop polecenia do przetestowania komunikacji wychodzącej z adresem 13.107.21.200 w obszarze Użyj następnego przeskoku, trasa z adresemPrefix 0.0.0.0/0** została użyta do kierowania ruchu do adresu, ponieważ żadna inna trasa w danych wyjściowych nie zawiera adresu. Domyślnie wszystkie adresy, które nie zostały określone w prefiksie adresu innej trasy, są kierowane do Internetu.

Gdy użyto az network watcher show-next-hop polecenia do przetestowania komunikacji wychodzącej do adresu 172.31.0.100, wynik poinformował o tym, że nie ma typu następnego przeskoku. W zwróconych danych wyjściowych zobaczysz również następujący tekst:

{
  "additionalProperties": {
    "disableBgpRoutePropagation": false
      },
  "addressPrefix": [
    "172.16.0.0/12"
  ],
  "name": null,
  "nextHopIpAddress": [],
  "nextHopType": "None",
  "source": "Default",
  "state": "Active"
},

Jak widać w danych wyjściowych az network watcher nic show-effective-route-table polecenia, chociaż istnieje domyślna trasa do prefiksu 172.16.0.0/12, który zawiera adres 172.31.0.100, następny Typhop to Brak. Platforma Azure tworzy domyślną trasę dla zakresu adresów 172.16.0.0/12, ale nie określa typu następnego przeskoku, jeśli nie jest to wymagane. Jeśli na przykład dodano zakres adresów 172.16.0.0/12 do przestrzeni adresowej sieci wirtualnej, platforma Azure zmienia wartość nextHopType na sieć wirtualną dla trasy. Następnie zostanie wyświetlona kontrola Sieć wirtualna jako następna wartośćHopType.

Czyszczenie zasobów

Gdy grupa zasobów i wszystkie zawarte w niej zasoby nie będą już potrzebne, można je usunąć za pomocą polecenia az group delete.

az group delete --name myResourceGroup --yes

Następne kroki

W tym artykule utworzono maszynę wirtualną i zdiagnozowano routing sieciowy z maszyny wirtualnej. Uzyskano informacje o tworzeniu tras domyślnych na platformie Azure i przetestowano routing do dwóch różnych miejsc docelowych. Uzyskaj więcej informacji na temat routingu na platformie Azure i dowiedz się, jak tworzyć trasy niestandardowe.

W przypadku połączeń wychodzących maszyn wirtualnych można również określić opóźnienie i dozwolony i niedozwolony ruch sieciowy między maszyną wirtualną a punktem końcowym przy użyciu możliwości rozwiązywania problemów z połączeniem usługi Network Watcher. Możesz monitorować komunikację między maszyną wirtualną a punktem końcowym, takim jak adres IP lub adres URL w czasie, przy użyciu funkcji monitora połączeń usługi Network Watcher. Aby uzyskać więcej informacji, zobacz Monitorowanie połączenia sieciowego.

Udostępnij za pośrednictwem