Cloud Run naar lokaal VPN: Direct VPC-egress instellen

De tunnel staat, een VM bereikt de lokale server, en de Cloud Run-service loopt op dezelfde host in een time-out. Dat is het normale startpunt voor deze taak, en de tunnel is zelden wat er mis is. Een Cloud Run-revisie staat standaard niet in je VPC, en als dat wel zo is, gebruikt hij zijn eigen bronadressen in plaats van het VM-subnet dat je al hebt gerouteerd. De runbook hieronder koppelt de service, routeert het werkelijke bronbereik en bewijst daarna het pad vanaf de revisie die het verzoek heeft bediend. Voer het in die volgorde uit, want het overslaan van de eerste stap is de reden dat zoveel van deze gevallen eindigen in een VPN-wijziging die niets oplost.

Koppel de revisie voordat je de tunnel debugt

Cloud Run ondersteunt Direct VPC-egress, waarmee het verkeer van de service op een subnet in je VPC komt zonder een Serverless VPC Access-connector. Voor een bestaande service ziet de update er zo uit:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Vervang de plaatsaanduidingen, beoordeel wat de implementatie met live verkeer doet, en kies een subnet in de regio van de service met voldoende adrescapaciteit en de juiste netwerkmachtigingen.

Kies de egress-modus die bij de bestemming past

private-ranges-only stuurt de bestemmingen die het als privé classificeert via de VPC. Dat betekent niet „alles wat via de VPN bereikbaar is”, en die kloof verschijnt wanneer de lokale service in een bereik ligt dat de instelling niet zo classificeert. Als de bestemming niet gedekt is, is all-traffic de andere gedocumenteerde modus, en die stuurt alles via de VPC, inclusief de openbare afhankelijkheden van de service. Kies bewust en schrijf het gevolg in het wijzigingsrecord.

Een service die al een connector gebruikt, vereist een migratie en geen schakelaar, dus plan die in plaats van beide te configureren.

Routeer de Cloud Run-bron, niet een VM-bron

Direct VPC-egress wijst tijdelijke adressen toe uit het gekozen subnet, en de lokale kant moet verkeer naar dat bereik terugsturen. Een retourroute of firewalltoestemming die voor een ander VM-subnet is geschreven, ziet er in het diagram correct uit en faalt in de praktijk. Neem de CIDR van het subnet uit de VPC en niet uit het geheugen, en bevestig dan dat de crypto-ACL of routetabel van het externe apparaat die bevat.

Controleer bij dynamische routering wat de Cloud Router werkelijk adverteert en wat de VPC importeert, inclusief elk aangepast advertentiebeleid. Een route die in de console bestaat maar niet voor deze bestemming is geselecteerd, is hetzelfde als geen route.

Drie voorwaarden die allemaal moeten gelden

Een werkend pad vereist alles van het volgende, en elk ervan faalt op zijn eigen manier:

• Een route in de VPC naar het lokale prefix via de beoogde Cloud VPN-verbinding.
• Een retourroute lokaal voor het Cloud Run-subnet.
• Een firewall- en IPsec-beschermingsbereik dat de bron, bestemming en poort toestaat.

Een ontbrekende route ziet er meestal uit als een time-out zonder bewijs aan de externe kant. Een probleem met de retourroute ziet eruit als een verzoek dat aankomt en een antwoord dat verdwijnt. Een firewall- of selectieprobleem kan er als een weigering of als een stille drop uitzien, afhankelijk van het apparaat. Bepalen welke van de drie je hebt, verkleint de volgende opdracht aanzienlijk.

Zet geen enkel tijdelijk Cloud Run-adres op de allowlist. Gebruik het subnetbereik en een autorisatieontwerp dat bij de toepassing past.

Test de revisie die het verzoek heeft bediend

Inspecteer de uitgerolde netwerkinstellingen en de verkeersverdeling voordat je test, want een update kan een nieuwe revisie maken terwijl verzoeken nog een oudere bereiken. Voer dan dezelfde bewerking uit die het verzoek van de gebruiker uitvoert, vanaf die revisie. Als de bestemming een privé-hostnaam is, controleer dan de resolutie in die omgeving en het adres dat die opleverde, want het corporate DNS-antwoord van je laptop bewijst niets over de namespace van de service. Behoud TLS-hostnaamverificatie en de eigen authenticatie van de externe toepassing.

Verwacht de gedocumenteerde Direct VPC-vertragingen bij het opstarten van verbindingen, en geef de client een gereedheids- of herprobeerstrategie in plaats van elke koude start als een kapotte tunnel te diagnosticeren.

Terugdraaien en wat dit niet doet

Om terug te draaien, zet de netwerk- en egress-instellingen van de service terug naar hun vorige waarden en bevestig dat de eerdere revisie nog verkeer bedient. Bewaar de gcloud-opdracht in het wijzigingsrecord, want het omgekeerde van een gedeeltelijke wijziging is zes weken later niet vanzelfsprekend. Het verwijderen van de VPC-koppeling brengt de service terug naar het vorige egress-pad, wat precies kan zijn wat je tijdens een incident wilt.

Dit ontwerp dekt verbindingen die Cloud Run initieert en hun antwoorden. Het geeft het lokale netwerk geen adresseerbare socket binnen de service, want blootstelling naar binnen is een ingress-beslissing.