API Google przez VPN: kieruj ruch na VIP, nie tylko na podsieć

Zaloguj się przez SSH na serwer lokalny, podnieś tunel, a prywatna VM odpowiada; potem pierwsze wywołanie API Google kończy się niepowodzeniem bez trasy. Podsieć VM i adresy VIP API to różne cele, więc trasa do jednego nie wybiera drugiego. Trzy warunki muszą być spełnione, zanim prywatne wywołanie API zadziała. Nazwa API musi rozwiązywać się do VIP, prefiks VIP musi być ogłaszany przez tunel, a VPC musi wiedzieć, jak odesłać odpowiedź. Ping nic z tego nie mówi, a działająca sesja SSH do maszyny w podsieci też nie.

Adresy VIP API to osobne cele

Google publikuje dedykowane adresy VIP do dostępu do API z sieci lokalnej, i to właśnie te adresy musi zwracać twój DNS dla nazw API. Oba są małymi prefiksami i żaden nie jest przestrzenią RFC 1918:

Adresy wyglądające publicznie nie znaczą, że trasa ma opuścić tunel dla zwykłego internetu. Prefiksy istnieją po to, aby klient lokalny dotarł do frontendów Google wspieraną ścieżką, a nie przez dowolny punkt wyjścia. Traktuj je jako cele należące do tunelu, nie jako hosty do sondowania. Reguła zapory napisana dla wyjścia do internetu zwykle je odrzuca, i to jest częsty powód, dla którego wywołanie zawodzi, zanim się zacznie.

DNS decyduje, który punkt końcowy osiągniesz

Skieruj lokalny resolver na rekordy, które Google dokumentuje dla wybranego punktu końcowego, aby nazwy potrzebne aplikacji odpowiadały tym adresem VIP. Samo googleapis.com nie jest inwentarzem: rejestry pakietów, rejestry kontenerów i łączniki migracji mają własne udokumentowane nazwy. Ograniczony VIP też nie niesie każdej usługi, więc nazwa, która się rozwiązuje, może nadal być nieobsługiwana. Zapisz domeny, z którymi aplikacja faktycznie się łączy, zanim dotkniesz resolvera.

Zgadywanie adresu VM w VPC zamiast nazwy usługi nie jest naprawą i zwykle ukrywa lukę w DNS, dopóki nie zawiedzie inny klient.

Ogłaszaj prefiks VIP, zachowaj resztę

Przy połączeniu opartym na BGP Cloud Router musi ogłaszać wybrany prefiks VIP, aby router lokalny nauczył się tego zakresu przez zamierzoną sesję. Ogłaszanie samych podsieci VPC nie dodaje tego zakresu, a router lokalny nadal używa swojej domyślnej trasy dla tych adresów. Prefiks w tabeli routingu jest jedynym dowodem, że ogłoszenie przekroczyło sesję.

Zachowaj istniejące ogłoszenia, dodając nowe, bo opcje na poziomie routera i na poziomie peera mają inny zasięg, a zamiana zestawu może wycofać sieci, które już działały. Potem sprawdź skuteczne ogłoszenie w każdej sesji, a nie na routerze jako całości. Brakujący prefiks i wycofany prefiks wyglądają z lokalnej strony tak samo, więc to widok sesji oddziela pominięcie od regresji.

Strona VPC potrzebuje własnej trasy i ścieżki powrotnej

Wewnątrz VPC ścieżka VIP musi używać domyślnej bramy internetowej jako następnego skoku, i mimo nazwy ten ruch pozostaje w sieci Google. VPC potrzebuje też trasy powrotnej do źródła lokalnego przez VPN, a to osobny obiekt od ogłaszanego prefiksu. Uwzględnij udokumentowane regionalne wymagania routingu, gdy tunel i klient nie są w tym samym regionie.

Sprawdzaj ścieżkę powrotną niezależnie, bo działający kierunek żądania może ukryć zepsuty kierunek odpowiedzi. Dwa kierunki, dwie trasy i każda zawodzi z własnym objawem.

Przetestuj żądanie, a potem przeczytaj odrzucenie

Echo ICMP nie otrzymuje odpowiedzi od tych adresów VIP, więc nieudany ping niczego nie dowodzi, a udany bardzo mało. Od rzeczywistego klienta sprawdź odpowiedź nazwy i wybraną trasę, a następnie wykonaj autoryzowane żądanie HTTPS do usługi, na której ci zależy. Jeśli żądanie dotrze do usługi i zostanie odrzucone, sprawdź poświadczenia, IAM i wszelkie obowiązujące zasady obwodu usługi.

Routing prywatny nie daje autoryzacji API i nie zmienia tego, co tożsamość może robić. Sukces transportu i autoryzowana odpowiedź to osobne wyniki, i potrzebujesz obu. Utrzymuj też jawną ścieżkę IPv6, bo konfiguracja prefiksów IPv4 nic nie mówi o kliencie, który woli IPv6.

Przewodnik Google po Private Google Access z sieci lokalnej obejmuje razem rekordy DNS i wymagania routingu, więc porównuj ustawienia resolvera i ogłaszania z nim, a nie z postem na forum. Potem powtórz to samo żądanie i zapisz odpowiedź oraz trasę w tym samym zgłoszeniu.