App Engine può raggiungere il vostro database VPN: cosa deve coincidere

L'affermazione secondo cui App Engine Standard non può raggiungere un database privato tramite Cloud VPN è un residuo di una generazione precedente della piattaforma. Le istanze Standard non ricevono un indirizzo nativo VPC come alcuni altri runtime, ma possono inviare egress attraverso un connettore Serverless VPC Access che vive nella vostra rete. Una volta che quel percorso esiste, Cloud VPN e il firewall remoto vedono il traffico del connettore come qualsiasi altra origine. Ciò che fallisce è raramente la capacità in sé. È una delle tre impostazioni che non sono mai state allineate.

Da dove veniva la vecchia risposta

Prima che esistessero i connettori, la risposta pratica era davvero che Standard poteva parlare solo con endpoint pubblici, e i team passavano a una VM proxy o a un altro runtime per aggirarlo. La piattaforma è cambiata, il folklore no. Molti consigli online riflettono ancora l'epoca in cui non esisteva alcuna opzione di egress.

La correzione è più stretta di quanto sembri. Standard può raggiungere la rete privata, ma solo tramite un'integrazione di egress supportata, e solo per le destinazioni che quell'integrazione cattura davvero.

Scegliete prima il percorso di egress

È un connettore collegato al servizio a mettere il suo traffico nella VPC. La documentazione del connettore elenca il prerequisito regionale e le impostazioni di egress; il connettore deve esistere nella regione del servizio ed essere utilizzabile dall'identità che esegue il deploy.

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

private-ranges-only invia le destinazioni private nella VPC e lascia tutto il resto sul percorso internet normale, che di solito è ciò di cui ha bisogno una connessione al database. all-traffic spinge il traffico in uscita attraverso la VPC in modo ampio, quindi anche le normali chiamate internet ereditano la postura NAT e firewall della VPC.

Modificare il file localmente non cambia nulla finché non eseguite il deploy. Una versione in esecuzione conserva la configurazione con cui è stata creata.

L'indirizzo di origine è il connettore, non il vostro portatile

È qui che va la maggior parte del tempo di debug. Il gateway VPN remoto e il firewall del database devono ammettere l'intervallo assegnato al connettore all'interno della VPC, non l'indirizzo del vostro ufficio e non l'indirizzo di egress pubblico del servizio. Cercate quell'intervallo nella console prima di scrivere anche una sola regola.

Altri due punti devono concordare. La tabella di routing della VPC ha bisogno di una rotta verso la rete remota del database, e il lato remoto ha bisogno di una rotta di ritorno per l'intervallo del connettore. Se il tunnel utilizza selettori di traffico, confermate che l'intervallo del connettore rientri nell'ambito negoziato. Una rotta che esiste solo nella direzione da remoto a locale è una mancanza comune, e lascia passare i ping senza mai completare un handshake TCP.

Un tunnel che ammette solo una sottorete VM scarterà i pacchetti del connettore senza un messaggio di errore utile, ed è per questo che il timeout del database sembra un problema di credenziali.

Il DNS viaggia su un percorso diverso

Un nome host di database privato deve risolversi all'interno della rete raggiunta dal connettore, tramite peering Cloud DNS o una zona di inoltro che la VPC può usare. Risolverlo sulla vostra workstation non prova nulla sul servizio distribuito, perché il vostro portatile non usa quel resolver.

Se il nome si risolve in un indirizzo pubblico dall'interno della VPC, state per fare debug del firewall sbagliato.

URL Fetch non usa il connettore

L'impostazione di egress copre i normali socket in uscita del runtime, e il servizio legacy URL Fetch non fa parte di quel percorso. Una richiesta emessa tramite urlfetch ignora il connettore qualunque cosa dica la configurazione. Quando la chiamata che fallisce si trova in una libreria più vecchia che usa ancora URL Fetch, la correzione è spostare quella chiamata sul client HTTP standard.

Per un driver di database questo è raramente il problema, ma è la ragione classica per cui un endpoint funziona e un altro no dallo stesso servizio.

Verificate con una singola query ristretta

Eseguite il deploy, poi eseguite una sola operazione di database consentita dalla versione distribuita osservando il lato remoto. L'indirizzo di origine registrato dal database o dal gateway VPN dovrebbe essere quello del connettore. Se non lo è, la richiesta non è mai entrata nella VPC e nessuna configurazione del tunnel lo risolverà. Confrontatelo con l'intervallo che avete cercato nella console; una discrepanza di solito significa che un secondo connettore serve la versione.

Una query riuscita da una VM all'interno della VPC stabilisce che la rotta esiste. Non stabilisce che il servizio l'abbia scelta.