Cloud VPN do VM w GCP: używaj adresu IP wewnętrznego, a nie NAT

Gdy sieć lokalna dociera do VPC przez Cloud VPN, celem usługi Compute Engine jest zwykle wewnętrzny adres VM. Zewnętrzny adres IPv4 nie jest drugim adresem, który można podstawić do tej samej prywatnej trasy. Większość zamieszania w tym obszarze wynika z traktowania trzech adresów o trzech zadaniach jako wymiennych, więc zacznij od nazwania, którego używa dany pakiet.

Trzy adresy, trzy zadania

Nazwij wszystkie trzy, zanim zaczniesz debugować którykolwiek z nich, bo odpowiedź zmienia obiekt, który sprawdzisz jako następny.

Pierwszy należy do tunelu. Drugi należy do projektu trasy i zapory. Trzeci należy do dostępu przychodzącego z internetu i jest mapowany, a nie podłączany. Projekt, który działa dla jednego z nich, nic nie mówi o pozostałych dwóch.

Dlaczego adres zewnętrzny nie jest drugim interfejsem

Przewodnik po adresowaniu jest źródłem wiedzy o tym, czym różni się dostępność wewnętrzna i zewnętrzna w Compute Engine. Zewnętrzny adres IPv4 w Compute Engine to mapowanie jeden do jednego na jedyny wewnętrzny NIC instancji, więc gość nigdy nie widzi drugiego interfejsu ani drugiego adresu na tym NIC. To, co VM zgłasza od środka, to nadal jeden główny adres wewnętrzny.

Dlatego prywatny klient kierujący ruch przez tunel do 10.24.1.7 i klient celujący w zewnętrzny adres VM znajdują się na różnych ścieżkach. Otwarcie reguły zapory dla adresu publicznego niczego nie zmienia w trasie VPC, która musi przenosić ruch tunelu, a edycja trasy na gościu nie przesuwa mapowania platformy. Wybierz adres, który nazywa Twoja trasa, a następnie sprawdzaj tylko obiekty, które nim zarządzają. Ta dyscyplina usuwa większość zgadywania z tej ścieżki rozwiązywania problemów.

Przejdź ścieżkę z gcloud

Zacznij od instancji i odczytaj oba adresy z tego samego obiektu, aby wiedzieć, o którym mówi Twoja dokumentacja:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Następnie potwierdź trasowanie i uprawnienie, od których ścieżka faktycznie zależy:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Odczytaj ogłaszane i poznane zakresy tunelu, trasę VPC dla podsieci obciążenia i regułę zapory, która zezwala na źródło lokalne. Te trzy muszą się zgadzać, zanim odbiornik na gościu będzie w ogóle istotny.

Następnie sprawdź gościa: czy usługa nasłuchuje na adresie wewnętrznym i czy jej ścieżka powrotna przechodzi z powrotem przez VPC? Odbiornik powiązany tylko z adresem publicznym nie przejdzie tego testu, nawet gdy każdy obiekt po stronie chmury jest poprawny.

Publiczny prefiks to inne pytanie

Nic z powyższego nie oznacza, że każdy adres przenoszony wewnątrz VPN musi być RFC1918. Sieć zdalna może być legalnie numerowana z przestrzeni publicznej, pod warunkiem że platforma obsługuje trasowanie i operator ma uprawnienia do adresu. To normalny wybór projektowy.

To nie to samo, co traktowanie zwykłego zewnętrznego adresu NAT jakby był kolejnym wewnętrznym adresem podsieci. Jeden jest prefiksem, który trasujesz; drugi jest mapowaniem, które platforma stosuje do dostępu przychodzącego.

Zewnętrzny IPv6 i specjalnie zaprojektowane układy adresów mają własną semantykę. Jeśli Twój plan zależy od któregoś z nich, przeczytaj dokumentację platformy dla tej funkcji, zamiast uogólniać z przypadku IPv4. Mapowanie IPv4 to typowy przypadek, nie jedyny, a wyjątki mają własne reguły.

Nakładające się zakresy to inny problem

Nakładające się zakresy prywatne to realny powód, dla którego ludzie sięgają po adres publiczny, i to jest niewłaściwa dźwignia. Zmiana celu na adres NAT VM nie rozwiązuje nakładania; zmienia adres, dla którego pakiet twierdzi, że jest przeznaczony, nie definiując, jak działa ścieżka powrotna.

Rozwiąż nakładanie świadomie: przenumeruj, użyj obsługiwanego projektu tłumaczenia albo trasuj przez sieć, w której prefiksy nie kolidują. Każde z tych rozwiązań to projekt z właścicielem. Adres NAT nie jest projektem.

Dokumentuj oba pola osobno

Zapisz peera tunelu i cel obciążenia jako dwa osobne pola runbooka, każde z trasą i regułą zapory, które je wspierają. Tunel IPsec, który się podniesie, mówi tylko, że strony się zgadzają; nie mówi nic o tym, pod jakim adresem obciążenie jest osiągalne ani czy jego prywatna trasa jest kompletna.

Zweryfikuj prawdziwym klientem po drugiej stronie: rozwiąż nazwę, potwierdź, że zwraca adres wewnętrzny, połącz się i sprawdź ruch powrotny. Dokumentacja adresów IP Compute Engine jest odniesieniem dla użytego powyżej rozróżnienia na wewnętrzne i zewnętrzne.