Umożliwienie łączenia do usług IPv4 dla workloadów bazujących na IPv6

Pod koniec lutego 2022, AWS ogłosił dwie nowe możliwości dla bramy Amazon Virtual Private Cloud (VPC) NAT gateway  i Amazon Route 53, umożliwiające przejrzystą komunikację workloadów obsługujących tylko protokół IPv6 z usługami obsługującymi tylko protokół IPv4.

Niektórzy z was uruchamiają bardzo duże workloady obejmujące dziesiątki tysięcy maszyn wirtualnych, kontenerów lub mikro-usług. W tym celu te workloady zwykle konfigurowane są do pracy w przestrzeni adresowej IPv6. Pozwala to uniknąć problemu wyczerpania dostępnych adresów IPv4 (pojedynczy VPC ma maksymalny teoretyczny rozmiar 65 536 adresów IPv4, w porównaniu z zakresami /56 dla IPv6, co pozwala na maksymalny teoretyczny rozmiar 2^73 -1 adresów IPv6), a także chroni to przed dodatkowymi problemami spowodowanymi zarządzaniem złożonymi sieciami opartymi na IPv4 (pomyśl o nienakładających się podsieciach między VPC należącymi do wielu kont AWS, regionów AWS lub sieci lokalnych).

Ale czy naprawdę możesz uruchomić workload IPv6 w oderwaniu od reszty świata IPv4? Większość z Was powiedziałaby, że ważne jest, aby takie workloady nadal komunikowały się z usługami IPv4, aby albo wykonywać wywołania do starszych interfejsów API, albo po prostu jako projekt przejściowy podczas migracji wielu zależnych workloadów z IPv4 do IPv6. Brak możliwości wywołania usługi IPv4 z hostów IPv6 sprawia, że migracje są wolniejsze i trudniejsze niż jest to konieczne. To zmusiło niektórych z Was do budowania niestandardowych rozwiązań, które są trudne w utrzymaniu.

Właśnie dlatego AWS wprowadził dwie nowe możliwości umożliwiające przejrzystą komunikację workloadów IPv6 z usługami IPv4: NAT64 (czytaj „sześć do czterech”) dla bramy VPC NAT i DNS64 (również „sześć do czterech”) dla Amazon Route 53 resolver.

Jak to działa?

Jak ilustruje poniższy diagram, wyobraźmy sobie, że mamy Amazon Elastic Compute Cloud (Amazon EC2) z adresem tylko IPv6, która musi wykonać wywołanie API do usługi IPv4 działającej na innej instancji EC2. Na diagramie wybraliśmy hosta obsługującego tylko protokół IPv4 w oddzielnym VPC na tym samym koncie AWS, ale te możliwości działają w celu połączenia z dowolną usługą IPv4, zarówno w tym samym VPC, jak i w VPC innego konta AWS, sieci typu on-premises, a nawet w publicznym Internecie. Nasz host obsługujący tylko protokół IPv6 zna tylko nazwę DNS usługi.

Oto sekwencja, która ma miejsce, gdy host obsługujący wyłącznie protokół IPv6 inicjuje połączenie z usługą IPv4:

1. Host IPv6 wykonuje wywołanie DNS, aby przetłumaczyć nazwę usługi na adres IP. Bez DNS64, usługa Route 53 zwróciłaby adres IPv4. Hosty obsługujące tylko protokół IPv6 nie byłyby w stanie połączyć się z tym adresem IPv4. Od lutego możesz włączyć DNS64 dla swojej podsieci. DNS resolver najpierw sprawdza, czy rekord zawiera adres IPv6 (rekord AAAA). Jeśli tak, zwracany jest adres IPv6. Host IPv6 może łączyć się z usługą za pomocą samego protokołu IPv6. Gdy rekord zawiera tylko adres IPv4, Route 53 resolver syntetyzuje adres IPv6, dołączając dobrze znany 64:ff9b::/96 do adresu IPv4.

Na przykład, gdy usługa IPv4 ma adres address 34.207.250.62, Route 53 zwraca 64:ff9b::ffff:22cf:fa3e.

64:ff9b::/96 to dobrze znany prefiks zdefiniowany w proponowanym przez RFC 6052 standardzie dla IETF. Czytanie o standardach internetowych to świetny sposób na poznanie wszystkich szczegółów dotyczących tłumaczenia IPv6 na IPv4.

2. Host IPv6 inicjuje połączenie z 64:ff9b::ffff:22cf:fa3e. Możesz skonfigurować routing podsieci, aby wysyłać wszystkie pakiety zaczynające się od 64:ff9b::/96do bramy NAT. Brama NAT rozpoznaje prefiks adresu IPv6, wyodrębnia z niego adres IPv4 i inicjuje połączenie IPv4 do miejsca docelowego. Jak zwykle, źródłowy adres IPv4 jest adresem IPv4 samej bramy NAT.

3. Po nadejściu odpowiedzi pakietu brama NAT ponownie wypełnia adres IPv6 hosta docelowego i dołącza dobrze znany prefiks 64:ff9b::/96 do źródłowego adresu IP pakietu odpowiedzi.

Teraz kiedy rozumiesz, jak to działa, jak skonfigurować VPC, aby wykorzystać te dwie nowe możliwości?

Jak rozpocząć

Aby uruchomić te dwie funkcjonalności, musimy dostosować dwie konfiguracje: po pierwsze, oznaczamy podsieci, które wymagają translacji DNS64, a po drugie, dodajemy trasę do tablicy routingu podsieci IPv6, aby wysłać część ruchu IPv6 do bramy NAT.

Aby uruchomić DNS64, musimy użyć nowej opcji --enable-dns64, aby modyfikować istniejące podsieci. W tym demo używamy atrybutu modify-subnet-attribute. To jest jednorazowa operacja. Możemy to zrobić za pomocą konsoli AWS Command Line Interface (CLI) lub AWS Management Console. Zauważ, że jest to konfiguracja na poziomie podsieci, która musi być jawnie włączona. Domyślnie zachowywane jest istniejące zachowanie.

aws ec2 modify-subnet-attribute --subnet-id subnet-123 --enable-dns64

Musimy dodać trasę do tabeli routingu podsieci, aby umożliwić VPC przekazywanie pakietów IPv6 z prefiksem DNS64 do bramy NAT. Wymusza to, aby kierować wszystkie pakiety z miejscem docelowym 64:ff9b::/96 do bramy NAT.

aws ec2 create-route --route-table-id rtb-123 –-destination-ipv6-cidr-block 64:ff9b::/96 –-nat-gateway-id nat-123

Poniższy diagram ilustruje te dwie proste zmiany konfiguracji.

Dzięki tym dwóm prostym zmianom nasze workloady obsługujące tylko protokół IPv6 w podsieci mogą teraz komunikować się z usługami IPv4. Usługa IPv4 może działać w tym samym VPC, w innym VPC lub w dowolnym miejscu w internecie.

Możesz nadal korzystać z istniejącej bramy NAT i nie są wymagane żadne zmiany w samej bramie ani w tabeli routingu dołączonej do podsieci bramy NAT.

Koszty i dostępność

Te dwie nowe możliwości bramy VPC NAT i Route 53 są już dostępne we wszystkich regionach AWS bez dodatkowych kosztów. Mogą obowiązywać zwykłe opłaty za bramkę NAT.

źródło: AWS