AWS VPC Reachability Analyzer w akcji

Jakiś czas temu, przyszło mi konfigurować mikrotika na AWS EC2 z wykorzystaniem obrazu RouterOS v7. Wszystko zostało skonfigurowane, ale miałem taki problem, że nie mogłem pingować maszyn podpiętych do mikrotika między sobą, Security Group reguły dopuszczały takich ruch, NAT w mikrotiku również zezwalał na takich ruch. Zaczynało brakować mi pomysłów w czym może być problem i na ratunek przyszło narzędzie od AWS, które nazywa się VPC Reachability Analyzer.

1. Co to jest VPC Reachability Analyzer?

Jest to proste narzędzie do analizy konfiguracji naszej sieci, dzięki któremu możemy przeprowadzić test łączności pomiędzy zasobem źródłowym, a zasobem docelowym w chmurze AWS, takim zasobem mogą być np instancje EC2. W tym artykule zobaczymy to narzędzie w akcji, będziemy do tego potrzebowali instancje EC2 w publicznej sieci z SG bez jakiejkolwiek reguły.

2. Tworzenie path

W tym kroku zajmiejmy się utworzeniem „path”, czyli ścieżki, która ma określić co i skąd będziemy sprawdzali. W naszym wypadku, będziemy sprawdzać dostęp do instancji EC2, poprzez Internet Gateway na porcie 22. Tworzymy sobie plik source-filter.json z konfiguracją portu, który będziemy sprawdzać, dodajemy do niego poniższy kod

{
    "DestinationPortRange": {
        "FromPort": 22,
        "ToPort": 22
    }
}

Następnie wykonujemy poniższe polecenie

aws ec2 create-network-insights-path --source identyfikator_igw --destination identyfikator_instancji_ec2  --protocol TCP --filter-at-source file://source-filter.json

W miejscu identyfikator_igw podajemy ID naszego Internet Gateway, który jest przypisany do publicznego subnetu naszej instancji EC2, natomiast w miejscu identyfikator_instancji_ec2 dajemy identyfikator naszej instancji. Po wykonaniu polecenia, powinniśmy dostać podobny wynik do mojego

{
  "NetworkInsightsPath": {
    "NetworkInsightsPathId": "nip-0918e37567fd1015b",
    "NetworkInsightsPathArn": "arn:aws:ec2:eu-central-1:111111111111:network-insights-path/nip-0918e37567fd1015b",
    "CreatedDate": "2024-10-16T13:45:24.928000+00:00",
    "Source": "identyfikator_igw",
    "Destination": "identyfikator_instancji_ec2",
    "SourceArn": "arn:aws:ec2:eu-central-1:111111111111:internet-gateway/identyfikator_igw",
    "DestinationArn": "arn:aws:ec2:eu-central-1:111111111111:instance/identyfikator_instancji_ec2",
    "Protocol": "tcp",
    "FilterAtSource": {
      "DestinationPortRange": {
        "FromPort": 22,
        "ToPort": 22
      }
    }
  }
}

Dla nas w tym momencie najważniejsze jest zapisanie gdzieś na boku NetworkInsightsPathId, w moim wypadku jest to nip-0918e37567fd1015b

3. Analiza utworzonej ścieżki

Utworzyliśmy ścieżkę oraz zapisaliśmy numer nip, w tym kroku uruchomimy proces analizy, poprzez poniższe polecenie

aws ec2 start-network-insights-analysis --network-insights-path-id identyfikator_nip

Wynik zapytania powinien wyglądać jak poniżej

{
    "NetworkInsightsAnalysis": {
        "NetworkInsightsAnalysisId": "nia-030cc7f41722495b4",
        "NetworkInsightsAnalysisArn": "arn:aws:ec2:eu-central-1:177394270612:network-insights-analysis/nia-030cc7f41722495b4",
        "NetworkInsightsPathId": "nip-0918e37567fd1015b",
        "StartDate": "2024-10-16T14:05:12.049000+00:00",
        "Status": "running"
    }
}

Dla nas najważniejszy jest status, w naszym wypadku jest running, więc wszystko udało się zgodnie z oczekiwaniami 🙂 W tym momencie musimy sobie skopiować identyfkator nia z pola NetworkInsightsAnalysisId, ponieważ zaraz będzie nam potrzebny do sprawdzenia wyniku.

4. Sprawdzanie wyniku

Aby sprawdzić wynik analizy, należy wykonać poniższe polecenie i podstawić swój identyfikator nia, otrzymany z poprzedniego polecenia

aws ec2 describe-network-insights-analyses --network-insights-analysis-ids identyfikator_nia

W odpowiedzi otrzymaliśmy poniższe wartości

„Status”: „succeeded”,
„NetworkPathFound”: true

Co oznacza, że nasza wirtualna maszyna jest dostępna z zewnątrz po porcie SSH, więc teraz mamy pewność, że jest wszystko ok. Teraz dla przykładu wykrycia problemu z łącznością, możecie z Security Group przypisanej do EC2 wyrzucić wpis, zezwalający na ruch po porcie 22 i ponownie odpalić analizę ścieżki. W tym wypadku, w odpowiedzi powinniście dostać:

„Status”: „succeeded”,
„NetworkPathFound”: false

Co oznacza, że nasza maszyna nie jest dostępna po porcie 22. Problem jaki narzędzie trafiło po drodze będzie opisany w wyniku analizy w polu „Explanations„, a dokładnie „ExplanationCode„. Tutaj zwrotka nie wiele mówi, natomiast można wejść sobie na konsolę AWS i tak będzie wszystko dokładnie opisane i jako błąd, będzie wymienione brak reguły w Security Group.

I to na tyle, jezeli chodzi o narzędzie VPC Reachability Analyzer oraz przykład jego wykorzystania 🙂 Mam nadzieję, że powyższy artykuł pomoże Wam w szybszym rozwiązywaniu problemu z siecami na AWS 🙂