Cloud Run verso VPN locale: configurare l'uscita diretta VPC

Il tunnel è attivo, una VM raggiunge il server locale e il servizio Cloud Run va in timeout sullo stesso host. È il punto di partenza normale di questa attività, e il tunnel è raramente ciò che non funziona. Una revisione Cloud Run non risiede nella vostra VPC per impostazione predefinita, e quando lo fa usa i propri indirizzi di origine invece della subnet VM che avete già instradato. Il runbook seguente collega il servizio, instrada il suo intervallo di origine reale e poi dimostra il percorso dalla revisione che ha servito la richiesta. Eseguitelo in quest'ordine, perché saltare il primo passo è la ragione per cui tanti di questi casi finiscono con un cambio di VPN che non corregge nulla.

Collegate la revisione prima di eseguire il debug del tunnel

Cloud Run supporta l'uscita diretta VPC, che mette il traffico del servizio su una subnet nella vostra VPC senza un connettore Serverless VPC Access. Per un servizio esistente l'aggiornamento appare così:

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

Sostituite i segnaposto, esaminate cosa fa il deployment al traffico live e scegliete una subnet nella regione del servizio con capacità di indirizzi sufficiente e le autorizzazioni di rete corrette.

Scegliete la modalità di uscita adatta alla destinazione

private-ranges-only invia le destinazioni che classifica come private attraverso la VPC. Non significa «qualunque cosa raggiungibile tramite la VPN», e questo divario emerge quando il servizio locale si trova in un intervallo che l'impostazione non classifica in quel modo. Se la destinazione non è coperta, all-traffic è l'altra modalità documentata, e invia tutto attraverso la VPC, comprese le dipendenze pubbliche del servizio. Scegliete deliberatamente e scrivete la conseguenza nel registro dei cambi.

Un servizio che usa già un connettore richiede una migrazione, non un interruttore, quindi pianificatela invece di configurare entrambi.

Instradate l'origine Cloud Run, non un'origine VM

L'uscita diretta VPC assegna indirizzi effimeri dalla subnet scelta, e il lato locale deve restituire il traffico a quell'intervallo. Una rotta di ritorno o un'autorizzazione del firewall scritta per un'altra subnet VM sembrerà corretta nel diagramma e fallirà nella pratica. Prendete il CIDR della subnet dalla VPC e non dalla memoria, poi confermate che l'ACL crittografico o la tabella di routing del dispositivo remoto lo includa.

Con il routing dinamico, verificate cosa annuncia realmente Cloud Router e cosa importa la VPC, inclusa qualsiasi politica di annuncio personalizzata. Una rotta che esiste nella console ma non è selezionata per questa destinazione equivale a nessuna rotta.

Tre condizioni che devono valere tutte

Un percorso funzionante richiede tutto quanto segue, e ciascuna condizione fallisce a modo suo:

• Una rotta nella VPC verso il prefisso locale tramite la connessione Cloud VPN prevista.
• Una rotta inversa in locale per la subnet Cloud Run.
• Un ambito di protezione del firewall e IPsec che consenta origine, destinazione e porta.

Una rotta mancante di solito appare come un timeout senza prove sul lato remoto. Un problema di rotta inversa appare come una richiesta che arriva e una risposta che scompare. Un problema di firewall o di selettore può apparire come un rifiuto o come una caduta silenziosa, a seconda del dispositivo. Stabilire quale dei tre avete restringe molto il comando successivo.

Non inserite un solo indirizzo Cloud Run temporaneo nella lista consentita. Usate l'intervallo della subnet e un progetto di autorizzazione adatto all'applicazione.

Testate la revisione che ha servito la richiesta

Esaminate le impostazioni di rete distribuite e la ripartizione del traffico prima di testare, perché un aggiornamento può creare una nuova revisione mentre le richieste raggiungono ancora una più vecchia. Poi eseguite la stessa operazione che esegue la richiesta dell'utente, da quella revisione. Se la destinazione è un nome host privato, verificate la risoluzione in quell'ambiente e l'indirizzo prodotto, perché la risposta DNS aziendale del vostro portatile non dimostra nulla sullo spazio dei nomi del servizio. Mantenete la verifica del nome host TLS e l'autenticazione propria dell'applicazione remota.

Aspettatevi i ritardi di connessione all'avvio di Direct VPC documentati, e date al client una strategia di disponibilità o di nuovo tentativo invece di diagnosticare ogni avvio a freddo come un tunnel rotto.

Rollback e ciò che questo non fa

Per tornare indietro, ripristinate le impostazioni di rete e di uscita del servizio ai valori precedenti e confermate che la revisione precedente serve ancora traffico. Conservate il comando gcloud nel registro dei cambi, perché l'inverso di un cambiamento parziale non è ovvio sei settimane dopo. Rimuovere il collegamento alla VPC riporta il servizio al percorso di uscita precedente, che potrebbe essere esattamente ciò che volete durante un incidente.

Questo progetto copre le connessioni che Cloud Run avvia e le relative risposte. Non dà alla rete locale un socket indirizzabile all'interno del servizio, perché l'esposizione in ingresso è una decisione di ingress.