App Engine kan jou VPN-databasis bereik: dit is wat moet ooreenstem

Die bewering dat App Engine Standard nie 'n private databasis oor Cloud VPN kan bereik nie, is 'n oorblyfsel uit 'n vroeër generasie van die platform. Standard-instanse kry nie 'n VPC-eie adres soos sommige ander looptye nie, maar hulle kan egress deur 'n Serverless VPC Access-connector stuur wat in jou netwerk lê. Sodra daardie pad bestaan, sien Cloud VPN en die afgeleë firewall connectorverkeer soos enige ander bron. Wat misluk, is selde die vermoë self. Dit is een van drie instellings wat nooit belyn gemaak is nie.

Waar die ou antwoord vandaan kom

Voordat connectors bestaan het, was die praktiese antwoord regtig dat Standard net met openbare eindpunte kon praat, en spanne het na 'n proxy-VM of 'n ander looptyd geskuif om dit te omseil. Die platform het verander, maar die volksverhaal nie. Baie aanlyn advies weerspieël steeds die tyd toe daar glad geen egress-opsie was nie.

Die regstelling is kleiner as wat dit klink. Standard kan die private netwerk bereik, maar net deur 'n ondersteunde egress-integrasie, en net vir die bestemmings wat daardie integrasie werklik vang.

Kies eers die egress-pad

'n Connector wat aan die diens gekoppel is, is wat sy verkeer in die VPC plaas. Die connectordokumentasie lys die streekvereiste en die egress-instellings; die connector moet in die diens se streek bestaan en deur die ontplooiingsidentiteit gebruik kan word.

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

private-ranges-only stuur private bestemmings in die VPC in en laat alles anders op die normale internetpad, wat gewoonlik is wat 'n databasisverbinding nodig het. all-traffic stuur uitgaande verkeer breedweg deur die VPC, so gewone internetoproepe erf ook die VPC se NAT- en firewall-houding.

Om die lêer plaaslik te wysig, verander niks voordat jy ontplooi nie. 'n Lopende weergawe hou die konfigurasie waarmee dit geskep is.

Die bronadres is die connector, nie jou skootrekenaar nie

Dit is waar die meeste ontfouttyd heen gaan. Die afgeleë VPN-gateway en die databasis-firewall moet die connector se toegewysde reeks binne die VPC toelaat, nie jou kantooradres nie en nie die diens se openbare egress-adres nie. Soek daardie reeks in die konsole op voordat jy 'n enkele reël skryf.

Nog twee plekke moet saamstem. Die VPC-roetetabel het 'n roete na die afgeleë databasisnetwerk nodig, en die afgeleë kant het 'n terugroete vir die connectorreeks nodig. As die tonnel verkeerskeurders gebruik, bevestig dat die connectorreeks binne die onderhandelde omvang sit. 'n Roete wat net in die rigting van afgeleë na plaaslik bestaan, is 'n algemene fout, en dit laat pings deur terwyl dit nooit 'n TCP-handdruk voltooi nie.

'n Tonnel wat net 'n VM-subnet toelaat, laat connectorpakke val sonder 'n nuttige foutboodskap, en daarom lyk die databasis se tydsverloop soos 'n geloofwaardigheidsprobleem.

DNS reis op 'n ander pad

'n Private databasis-gasheernaam moet binne die netwerk oplos wat die connector bereik, deur Cloud DNS-peering of 'n deurstuur-sone wat die VPC kan gebruik. Om dit op jou werkstasie op te los, bewys niks oor die ontplooide diens nie, want jou skootrekenaar gebruik nie daardie oplosser nie.

As die naam van binne die VPC na 'n openbare adres oplos, is jy op die punt om die verkeerde firewall te ontfout.

URL Fetch gebruik nie die connector nie

Die egress-instelling dek die looptyd se normale uitgaande sokkels, en die ou URL Fetch-diens is nie deel van daardie pad nie. 'n Versoek wat deur urlfetch uitgereik word, ignoreer die connector, maak nie saak wat die konfigurasie sê nie. Wanneer die mislukkende oproep in 'n ouer biblioteek sit wat steeds URL Fetch gebruik, is die oplossing om daardie oproep na die standaard HTTP-kliënt te skuif.

Vir 'n databasisdrywer is dit selde die probleem, maar dit is die klassieke rede waarom een eindpunt werk en 'n ander nie, uit dieselfde diens.

Verifieer met een nou query

Ontplooi, en voer dan 'n enkele toegelate databasisbewerking uit vanaf die ontplooide weergawe terwyl jy die afgeleë kant dophou. Die bronadres wat deur die databasis of die VPN-gateway aangeteken word, moet die connector s'n wees. As dit nie so is nie, het die versoek nooit die VPC binnegegaan nie, en geen hoeveelheid tonnelkonfigurasie sal dit regstel nie. Vergelyk dit met die reeks wat jy in die konsole opgesoek het; 'n wanverhouding beteken gewoonlik dat 'n tweede connector die weergawe bedien.

'n Suksesvolle query vanaf 'n VM binne die VPC bewys die roete bestaan. Dit bewys nie dat die diens dit gekies het nie.