App Engine może dotrzeć do Twojej bazy VPN: co musi się zgadzać

Twierdzenie, że App Engine Standard nie może dotrzeć do prywatnej bazy danych przez Cloud VPN, to pozostałość po wcześniejszej generacji platformy. Instancje Standard nie otrzymują adresu natywnego dla VPC jak niektóre inne środowiska uruchomieniowe, ale mogą wysyłać egress przez konektor Serverless VPC Access, który znajduje się w Twojej sieci. Gdy ta ścieżka istnieje, Cloud VPN i zdalny firewall widzą ruch konektora jak każde inne źródło. Zawodzi rzadko sama możliwość. To jedno z trzech ustawień, których nigdy nie wyrównano.

Skąd wzięła się stara odpowiedź

Zanim powstały konektory, praktyczna odpowiedź rzeczywiście brzmiała, że Standard może rozmawiać tylko z publicznymi punktami końcowymi, a zespoły przechodziły na maszynę VM proxy lub inne środowisko uruchomieniowe, aby to obejść. Platforma się zmieniła, folklor nie. Wiele porad w internecie wciąż odzwierciedla epokę, w której nie było żadnej opcji egress.

Poprawka jest węższa, niż brzmi. Standard może dotrzeć do sieci prywatnej, ale tylko przez obsługiwaną integrację egress i tylko do celów, które ta integracja faktycznie przechwytuje.

Najpierw wybierz ścieżkę egress

To konektor przypięty do usługi wprowadza jej ruch do VPC. Dokumentacja konektora wymienia regionalny warunek wstępny i ustawienia egress; konektor musi istnieć w regionie usługi i być użyteczny dla tożsamości wdrażającej.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only wysyła cele prywatne do VPC, a wszystko inne zostawia na normalnej ścieżce internetowej, czego zwykle potrzebuje połączenie z bazą danych. all-traffic przepycha ruch wychodzący szeroko przez VPC, więc zwykłe wywołania internetowe również dziedziczą postawę NAT i firewalla VPC.

Edycja pliku lokalnie niczego nie zmienia, dopóki nie wdrożysz. Działająca wersja zachowuje konfigurację, z którą została utworzona.

Adres źródłowy to konektor, nie Twój laptop

Tutaj idzie większość czasu debugowania. Zdalna brama VPN i firewall bazy danych muszą dopuścić zakres przydzielony konektorowi wewnątrz VPC, a nie adres Twojego biura i nie publiczny adres egress usługi. Znajdź ten zakres w konsoli, zanim napiszesz choć jedną regułę.

Dwa inne miejsca muszą się zgodzić. Tablica tras VPC potrzebuje trasy do zdalnej sieci bazy danych, a strona zdalna potrzebuje trasy powrotnej dla zakresu konektora. Jeśli tunel używa selektorów ruchu, potwierdź, że zakres konektora mieści się w wynegocjowanym zakresie. Trasa istniejąca tylko w kierunku od zdalnego do lokalnego to częste przeoczenie, a przepuszcza pingi, nigdy nie kończąc uścisku dłoni TCP.

Tunel, który dopuszcza tylko podsieć VM, odrzuci pakiety konektora bez użytecznego komunikatu o błędzie, dlatego przekroczenie limitu czasu bazy danych wygląda jak problem z poświadczeniami.

DNS podróżuje inną ścieżką

Nazwa hosta prywatnej bazy danych musi być rozwiązywana w sieci, do której dociera konektor, przez peering Cloud DNS lub strefę przekazywania, której VPC może użyć. Rozwiązanie jej na stacji roboczej niczego nie dowodzi o wdrożonej usłudze, bo Twój laptop nie używa tego resolvera.

Jeśli nazwa rozwiązuje się na publiczny adres spoza VPC, zaraz zaczniesz debugować niewłaściwy firewall.

URL Fetch nie używa konektora

Ustawienie egress obejmuje normalne gniazda wychodzące środowiska uruchomieniowego, a starsza usługa URL Fetch nie jest częścią tej ścieżki. Żądanie wysłane przez urlfetch ignoruje konektor, cokolwiek mówi konfiguracja. Gdy zawodzące wywołanie znajduje się w starszej bibliotece, która nadal używa URL Fetch, poprawką jest przeniesienie tego wywołania do standardowego klienta HTTP.

Dla sterownika bazy danych to rzadko bywa problemem, ale jest to klasyczny powód, dla którego jeden punkt końcowy działa, a inny nie w tej samej usłudze.

Sprawdź jednym wąskim zapytaniem

Wdróż, a następnie wykonaj jedną dozwoloną operację na bazie danych z wdrożonej wersji, obserwując stronę zdalną. Adres źródłowy rejestrowany przez bazę danych lub bramę VPN powinien być adresem konektora. Jeśli nie jest, żądanie nigdy nie weszło do VPC i żadna konfiguracja tunelu tego nie naprawi. Porównaj go z zakresem, który znalazłeś w konsoli; niezgodność zwykle oznacza, że wersję obsługuje drugi konektor.

Skuteczne zapytanie z VM wewnątrz VPC dowodzi, że trasa istnieje. Nie dowodzi, że usługa ją wybrała.