App Engine kan uw VPN-database bereiken: wat moet overeenkomen

De bewering dat App Engine Standard geen privédatabase via Cloud VPN kan bereiken, is een overblijfsel uit een eerdere generatie van het platform. Standard-instanties krijgen geen VPC-eigen adres zoals sommige andere runtime-omgevingen, maar ze kunnen egress sturen via een Serverless VPC Access-connector die in uw netwerk staat. Zodra dat pad bestaat, zien Cloud VPN en de externe firewall het verkeer van de connector als elke andere bron. Wat mislukt, is zelden de mogelijkheid zelf. Het is een van de drie instellingen die nooit zijn afgestemd.

Waar het oude antwoord vandaan kwam

Voordat connectors bestonden, was het praktische antwoord echt dat Standard alleen met openbare eindpunten kon praten, en teams stapten over op een proxy-VM of een andere runtime om dat te omzeilen. Het platform veranderde, de folklore niet. Veel online advies weerspiegelt nog steeds het tijdperk waarin er helemaal geen egress-optie was.

De correctie is smaller dan hij klinkt. Standard kan het privénetwerk bereiken, maar alleen via een ondersteunde egress-integratie, en alleen voor de bestemmingen die die integratie daadwerkelijk vastlegt.

Kies eerst het egress-pad

Een connector die aan de service is gekoppeld, brengt het verkeer in de VPC. De connectordocumentatie noemt de regionale voorwaarde en de egress-instellingen; de connector moet in de regio van de service bestaan en bruikbaar zijn door de identiteit die implementeert.

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

private-ranges-only stuurt privébestemmingen de VPC in en laat al het andere op het normale internetpad, wat een databaseverbinding meestal nodig heeft. all-traffic duwt uitgaand verkeer breed door de VPC, zodat gewone internetoproepen ook de NAT- en firewallhouding van de VPC erven.

Het bestand lokaal bewerken verandert niets tot u implementeert. Een draaiende versie behoudt de configuratie waarmee hij is gemaakt.

Het bronadres is de connector, niet uw laptop

Hier gaat het meeste debugtijd naartoe. De externe VPN-gateway en de databasefirewall moeten het aan de connector toegewezen bereik toelaten binnen de VPC, niet uw kantooradres en niet het openbare egress-adres van de service. Zoek dat bereik op in de console voordat u één regel schrijft.

Nog twee plaatsen moeten overeenkomen. De VPC-routetabel heeft een route naar het externe databasenetwerk nodig, en de externe kant heeft een retourroute nodig voor het bereik van de connector. Als de tunnel verkeersselectors gebruikt, bevestig dan dat het bereik van de connector binnen het onderhandelde bereik ligt. Een route die alleen in de richting van extern naar lokaal bestaat, is een veelgemaakte fout, en hij laat pings door zonder ooit een TCP-handshake te voltooien.

Een tunnel die alleen een VM-subnet toelaat, laat de pakketten van de connector vallen zonder bruikbare foutmelding, en daarom lijkt de time-out van de database op een inloggegevensprobleem.

DNS reist via een ander pad

Een privé-databasehostnaam moet worden opgelost binnen het netwerk dat de connector bereikt, via Cloud DNS-peering of een doorstuurzone die de VPC kan gebruiken. Het oplossen op uw werkstation bewijst niets over de geïmplementeerde service, want uw laptop gebruikt die resolver niet.

Als de naam van binnen de VPC naar een openbaar adres wordt herleid, staat u op het punt de verkeerde firewall te debuggen.

URL Fetch gebruikt de connector niet

De egress-instelling dekt de normale uitgaande sockets van de runtime, en de oude URL Fetch-service maakt geen deel uit van dat pad. Een verzoek via urlfetch negeert de connector, wat de configuratie ook zegt. Als de mislukkende aanroep in een oudere bibliotheek zit die nog URL Fetch gebruikt, is de oplossing die aanroep naar de standaard HTTP-client te verplaatsen.

Voor een databasedriver is dit zelden het probleem, maar het is de klassieke reden waarom het ene eindpunt werkt en het andere niet vanuit dezelfde service.

Controleer met één nauwe query

Implementeer, en voer daarna één toegestane databasebewerking uit vanuit de geïmplementeerde versie terwijl u de externe kant in de gaten houdt. Het bronadres dat de database of de VPN-gateway logt, zou dat van de connector moeten zijn. Is dat niet zo, dan is het verzoek nooit in de VPC gekomen en geen enkele tunnelconfiguratie lost dat op. Vergelijk het met het bereik dat u in de console hebt opgezocht; een afwijking betekent meestal dat een tweede connector de versie bedient.

Een geslaagde query vanaf een VM binnen de VPC bewijst dat de route bestaat. Het bewijst niet dat de service die heeft gekozen.