Cloud Run a VPN local: configuració de sortida directa de VPC

El túnel està actiu, una VM arriba al servidor local i el servei de Cloud Run expira al mateix amfitrió. Aquest és el punt de partida normal d'aquesta tasca, i el túnel poques vegades és el que falla. Una revisió de Cloud Run no se situa a la vostra VPC per defecte, i un cop ho fa, utilitza les seves pròpies adreces d'origen en lloc de la subxarxa de VM que ja heu encaminat. El runbook següent connecta el servei, encamina el seu rang d'origen real i després demostra el camí des de la revisió que va atendre la sol·licitud. Executeu-lo en aquest ordre, perquè saltar-se el primer pas és la raó per la qual tants d'aquests casos acaben en un canvi de VPN que no arregla res.

Connecteu la revisió abans de depurar el túnel

Cloud Run admet sortida directa de VPC, que posa el trànsit del servei en una subxarxa de la vostra VPC sense un connector de Serverless VPC Access. Per a un servei existent, l'actualització té aquest aspecte:

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

Substituïu els marcadors de posició, reviseu què fa el desplegament al trànsit en directe i trieu una subxarxa a la regió del servei amb prou capacitat d'adreces i els permisos de xarxa correctes.

Triu el mode de sortida que coincideixi amb la destinació

private-ranges-only envia les destinacions que classifica com a privades a través de la VPC. No vol dir «qualsevol cosa abastable per la VPN», i aquesta llacuna apareix quan el servei local se situa en un rang que la configuració no classifica així. Si la destinació no hi queda coberta, all-traffic és l'altre mode documentat, i envia tot a través de la VPC, incloent-hi les dependències públiques del servei. Trieu deliberadament i escriviu la conseqüència al registre de canvis.

Un servei que ja utilitza un connector és una migració, no un commutador, així que planifiqueu-la en lloc de configurar les dues coses.

Encamineu l'origen de Cloud Run, no l'origen d'una VM

La sortida directa de VPC assigna adreces efímeres de la subxarxa seleccionada, i el costat local ha de retornar el trànsit a aquest rang. Una ruta de retorn o una autorització de tallafoc escrita per a una altra subxarxa de VM semblarà correcta al diagrama i fallarà a la pràctica. Preneu el CIDR de la subxarxa de la VPC i no de la memòria, i després confirmeu que l'ACL criptogràfica o la taula d'encaminament del dispositiu remot l'inclou.

Amb encaminament dinàmic, verifiqueu què anuncia realment Cloud Router i què importa la VPC, incloent-hi qualsevol política d'anunci personalitzada. Una ruta que existeix a la consola però no està seleccionada per a aquesta destinació és el mateix que cap ruta.

Tres condicions que s'han de complir totes

Un camí funcional necessita tot el següent, i cadascuna falla a la seva manera:

• Una ruta a la VPC cap al prefix local a través de la connexió Cloud VPN prevista.
• Una ruta inversa al costat local per a la subxarxa de Cloud Run.
• Un abast de protecció de tallafoc i IPsec que permeti l'origen, la destinació i el port.

Una ruta que falta normalment sembla un temps d'espera sense cap evidència al costat remot. Un problema de ruta inversa sembla una sol·licitud que arriba i una resposta que desapareix. Un problema de tallafoc o de selector pot semblar un rebuig o una caiguda silenciosa, segons el dispositiu. Esbrinar quin dels tres teniu estreta molt la propera ordre.

No poseu una sola adreça temporal de Cloud Run a la llista d'autoritzats. Utilitzeu el rang de la subxarxa i un disseny d'autorització adequat per a l'aplicació.

Proveu la revisió que va atendre la sol·licitud

Inspeccioneu la configuració de xarxa desplegada i l'assignació de trànsit abans de provar, perquè una actualització pot crear una revisió nova mentre les sol·licituds encara arriben a una de més antiga. Després feu la mateixa operació que fa la sol·licitud de l'usuari, des d'aquella revisió. Si la destinació és un nom d'amfitrió privat, comproveu-ne la resolució en aquell entorn i l'adreça que ha produït, ja que la resposta del DNS corporatiu del vostre portàtil no demostra res sobre l'espai de noms del servei. Mantingueu la verificació del nom d'amfitrió TLS i l'autenticació pròpia de l'aplicació remota.

Espereu els retards de connexió d'inici de Direct VPC documentats, i doneu al client una estratègia de disponibilitat o reintent en lloc de diagnosticar cada inici en fred com un túnel trencat.

Revertir i què no fa això

Per revertir, torneu la configuració de xarxa i de sortida del servei als valors anteriors i confirmeu que la revisió anterior encara atén trànsit. Guardeu l'ordre gcloud al registre de canvis, perquè el revers d'un canvi parcial no és evident sis setmanes després. Treure l'adjunció de VPC retorna el servei al seu camí de sortida anterior, que pot ser exactament el que voleu durant un incident.

Aquest disseny cobreix les connexions que Cloud Run inicia i les seves respostes. No dona a la xarxa local un sòcol adreçable dins del servei, perquè l'exposició d'entrada és una decisió d'ingress.