La xarxa d'AlpinaShop es va dissenyar a 03-01 per a una situació que ja no existeix. Hi havia un projecte que importava, una aplicació a servir i una VPC amb dues subxarxes. Va funcionar perfectament durant quatre mòduls.

Avui la fotografia és una altra. Hi ha quatre projectes —alpinashop-prod, alpinashop-dev, alpinashop-datos i alpinashop-cicd— cadascun amb la seva pròpia VPC, sense saber res dels altres. La Lucía necessita que les seves consultes de BigQuery arribin a la rèplica alpinashop-pedidos-replica-informes, que viu en un altre projecte. El servei de Cloud Run que es va desplegar a 07-02 hauria de parlar amb Cloud SQL per IP privada en lloc de pel connector. La passarel·la de pagament exigeix que les peticions arribin des d'una IP fixa. I DA-004 va deixar compromès un túnel cap a l'ERP MySQL de la botiga de Sabadell que encara no existeix.

A més hi ha un risc que ningú no ha mirat: si demà es filtren les credencials de sa-informes-nocturnos, aquell compte pot llegir tot el dataset alpinashop_analitica i copiar-lo a un bucket de qualsevol altre projecte de Google Cloud del món. IAM autoritza la lectura; res no impedeix la sortida.

Aquesta lliçó resol les cinc coses. En acabar sabràs quan una VPC en un projecte deixa de bastar, dissenyaràs la VPC compartida d'AlpinaShop, distingiràs aparellament de xarxa compartida amb criteri, connectaràs la botiga de Sabadell amb Cloud VPN HA pas a pas entenent el BGP de debò, publicaràs i consumiràs serveis per IP privada amb Private Service Connect, aixecaràs un perímetre de VPC Service Controls al voltant de les dades, i sabràs diagnosticar una fallada de xarxa amb eines en lloc d'amb intuïció.

I sabràs on s'amaga la part de la factura que ningú no mira: el trànsit.

1. Quan una VPC en un projecte deixa de bastar
2. El disseny d'adreçament de tota l'organització
3. VPC compartida: projecte amfitrió i projectes de servei
4. Implementar la VPC compartida d'AlpinaShop
5. Aparellament de VPC: com funciona i què no fa
6. Taula de decisió: compartida, aparellament o interconnexió
7. Private Service Connect: serveis per IP privada
8. Connectivitat híbrida: les tres opcions per arribar a Sabadell
9. Cloud VPN HA pas a pas
10. Cloud Router, BGP i l'encaminament dinàmic de debò
11. Anunci de rutes i els errors que trenquen la connectivitat
12. Network Connectivity Center: la topologia radial gestionada
13. Controls de servei de VPC: el perímetre contra l'exfiltració
14. Diagnòstic de xarxa: Network Intelligence Center i una fallada real
15. Nivells de servei Premium i Estàndard
16. El cost del trànsit: on s'amaga la factura

Una VPC en un sol projecte és la resposta correcta durant més temps del que la gent es pensa. Aquests són els senyals concrets que se li ha quedat curta:

AlpinaShop marca sis dels set. És el moment.

Però abans de tocar res, cal fer el que gairebé ningú no fa i evita el 80 % dels problemes futurs.

Un pla d'adreçament és un full de càlcul amb quin rang fa servir cada cosa. Sona trivial. És el que separa una xarxa que creix d'una xarxa que cal refer.

La regla que ho governa tot:

Dos rangs que puguin arribar a connectar-se alguna vegada no es poden encavalcar. Mai. Sota cap circumstància.

I és més estricte del que sembla, perquè «alguna vegada» inclou: una fusió d'empreses, un proveïdor que es connecta per VPN, un núvol secundari, una oficina nova, un soci amb qui s'aparellen xarxes. Quan dos rangs s'encavalquen, no hi ha configuració que ho arregli: cal renumerar una de les dues xarxes, amb aturada de servei.

El pla d'AlpinaShop, dissenyat amb marge per a deu anys:

Quatre decisions que mereixen explicació:

1. Reservar 10.20.0.0/16 per a una segona regió encara que no es faci servir. Costa zero. El dia que 07-06 exigeixi multiregió, el rang és lliure i no cal negociar amb ningú.
2. Els rangs secundaris de GKE es reserven encara que el clúster es retiri. Els rangs de pods són enormes i devorar-los per sorpresa és un clàssic.
3. 10.10.240.0/20 per a accés a serveis privats. Quan crees una instància de Cloud SQL amb IP privada, Google necessita un rang dins de la teva VPC que et «treu» per al seu ús. Si no ho planifiques, te n'assigna un i després xoca amb alguna cosa.
4. Prohibir 172.16.0.0/12 explícitament. És el rang que fa servir Docker per defecte per a les seves xarxes pont. Qualsevol contenidor que faci servir aquell rang internament no podrà abastar una IP de la VPC en aquell mateix rang. És una tarda perduda garantida.

Consell: aquest pla viu al repositori alpinashop-infra com a fitxer DIRECCIONAMIENTO.md i es revisa al mateix pull request que crea la subxarxa. Un pla que és al full de càlcul d'algú no és un pla.

La VPC compartida (abans XPN, sigles que sobreviuen en algunes comandes i rols) permet que una VPC definida en un projecte sigui usada per recursos d'altres projectes.

La idea central, i és elegant:

La xarxa viu en un lloc. Els recursos viuen en un altre. La facturació i els permisos segueixen els recursos.

Una VM d'alpinashop-prod amb una IP de sn-web-euw1 es factura a alpinashop-prod, l'administren els permisos d'alpinashop-prod, i el seu trànsit obeeix les regles de tallafoc que són a alpinashop-red. Pot parlar amb una VM d'alpinashop-dev per IP privada perquè són a la mateixa VPC, encara que siguin projectes diferents.

Aquest repartiment és la raó de ser de la VPC compartida i la part que cal entendre:

Els dos rols que cal memoritzar:

• compute.xpnAdmin: qui pot vincular i desvincular projectes de servei. És un rol d'organització o carpeta, no de projecte. Molt poderós: es dona a una o dues persones.
• compute.networkUser: qui pot fer servir una xarxa o subxarxa. Es pot donar sobre la xarxa sencera (mala idea) o sobre una subxarxa concreta (el correcte).

Aquesta granularitat és la joia del model:

El Dani pot desplegar a sn-dev-euw1 perquè gcp-desarrollo@ té networkUser sobre aquella subxarxa. No pot desplegar a sn-datos-euw1, perquè no el té. Ni tan sols pot veure aquella subxarxa. I no pot tocar cap regla de tallafoc.

És separació de funcions (03-04) aplicada a la xarxa, i s'hereta automàticament per projecte nou si es gestiona amb Terraform.

Per a AlpinaShop, amb una persona de xarxa i tres projectes, la centralització és exactament el que vol: la Marta governa la xarxa, el Dani i la Lucía consumeixen subxarxes sense poder trencar-se entre ells.

Es fa en Terraform, com tot des de 06-07. Però primer la comanda equivalent, per entendre què passa.

La decisió de disseny més important: la xarxa va a un projecte propi, alpinashop-red, a la carpeta compartido. No a alpinashop-prod.

Per què? Perquè si la xarxa viu a producció, tothom qui necessiti tocar una subxarxa de desenvolupament necessita permisos al projecte de producció. El projecte amfitrió queda gairebé buit —només xarxa— i això és una virtut: la seva llista de permisos és curta i auditable.

Fixa't que alpinashop-cicd no es vincula: Cloud Build no necessita IP privada a la VPC per construir imatges, i cada vinculació és superfície que no cal.

Dos detalls amb conseqüències:

• routing_mode = "GLOBAL". Amb encaminament regional, les rutes que el Cloud Router aprèn per BGP a europe-west1 només s'anuncien a aquella regió. Si demà hi ha recursos a europe-southwest1, no arribaran a Sabadell. Canviar-ho després obliga a reiniciar les sessions BGP. Posa'l global des del principi.
• El compte serverless-robot-prod és l'agent de servei de Cloud Run. Quan un servei serverless fa servir VPC directa en una VPC compartida, és aquell compte, no el teu, el que necessita networkUser. És un permís que ningú no endevina i produeix un error críptic en desplegar.

Aquí ve la veritat incòmoda:

Una VM no es pot moure d'una VPC a una altra. Cal recrear-la a la xarxa nova.

La migració d'AlpinaShop, per sort, és senzilla gràcies al que ja s'ha fet:

Que la migració a VPC compartida sigui fàcil és un dividend directe d'haver mogut el catàleg a Cloud Run. Amb el MIG, caldria recrear les VM.

L'aparellament de VPC (VPC peering) connecta dues VPC perquè els seus recursos es parlin per IP privada, sense compartir administració.

Característiques:

• Trànsit per la xarxa interna de Google: baixa latència, gran amplada de banda.
• Sense cost per l'aparellament en si (el trànsit entre zones o regions sí que es paga).
• Funciona entre organitzacions diferents, a diferència de la VPC compartida.
• Cada costat manté el seu tallafoc i la seva administració.

I aquí les tres limitacions que defineixen quan serveix i quan no.

És la limitació més important i la que més gent descobreix tard.

Si A s'aparella amb B, i B amb C, A no pot parlar amb C. Ni afegint rutes, ni amb un proxy a B (això ja no és aparellament). Per a N xarxes que hagin de parlar-se totes amb totes calen N×(N−1)/2 aparellaments: 3 xarxes en són 3, 5 xarxes en són 10, 10 xarxes en són 45. Deixa de ser gestionable ràpid — i aquest és exactament el problema que resol Network Connectivity Center (apartat 12).

La conseqüència pràctica més habitual: una VPC aparellada no pot abastar a través teu la teva VPN a les oficines. És un cas que apareix constantment i sorprèn sempre.

Si A fa servir 10.1.0.0/16 i C també, no es poden aparellar mai. I no hi ha NAT que valgui a l'aparellament. És el motiu de l'apartat 2.

Les rutes, regles de reenviament i adreces internes se sumen entre xarxes aparellades a efectes de quota. En xarxes grans això esdevé un límit real.

Per defecte només s'intercanvien les rutes de les subxarxes. Es pot afinar:

--export-custom-routes és el que permet que l'altra VPC abasti, per exemple, la xarxa de Sabadell a través de la teva VPN. Està desactivat per defecte i és la causa número u de «l'aparellament està establert però no hi arribo».

La regla de decisió:

Els projectes són meus i vull una sola xarxa per governar? → VPC compartida. L'altra xarxa és d'algú altre, o necessito administracions separades? → Aparellament. Tinc més de cinc xarxes i seus que s'han de parlar totes? → Network Connectivity Center.

Private Service Connect (PSC) resol un problema diferent: consumir un servei per una IP privada de la teva pròpia VPC, sense aparellar xarxes i sense exposar res a internet.

Té tres usos, i convé distingir-los:

A 03-01 es va activar Private Google Access, que permet a una VM sense IP pública arribar a storage.googleapis.com fent servir el rang 199.36.153.8/30. Funciona, però el destí continua sent una IP de Google.

Amb PSC crees un extrem amb una IP del teu propi rang:

A partir d'aquí, 10.10.250.10 és el punt d'accés a les API de Google. Amb un registre DNS privat (*.googleapis.com → 10.10.250.10) tot el trànsit a les API hi passa.

Què es guanya davant de Private Google Access? Tres coses concretes:

1. Funciona des de fora de la VPC: des de Sabadell, a través del túnel VPN, una màquina pot arribar a 10.10.250.10 i fer servir Cloud Storage. Amb Private Google Access, no. Aquest és el motiu principal.
2. Una IP teva que pots controlar amb tallafoc i veure als Flow Logs.
3. És requisit habitual quan hi ha VPC Service Controls, amb el paquet vpc-sc en lloc d'all-apis.

Un SaaS —una plataforma de dades, un proveïdor de pagaments— publica el seu servei com a PSC. Tu crees un extrem a la teva VPC amb una IP teva, i consumeixes el servei sense sortir a internet, sense VPN i sense aparellar xarxes:

Avantatge decisiu sobre l'aparellament: no es comparteixen rangs ni rutes. El proveïdor no veu la teva xarxa i tu no veus la seva. Només s'exposa el servei concret. Per això PSC ha substituït l'aparellament com a forma estàndard de connectar amb proveïdors.

Simètricament, AlpinaShop podria publicar la seva API de socis darrere d'un balancejador intern i exposar-la com a service attachment perquè les botigues associades la consumeixin des de les seves pròpies VPC.

DA-004 va comprometre un enllaç privat amb la botiga. Hi ha tres maneres.

Per a AlpinaShop la decisió no té discussió. El trànsit previst són unes taules d'estoc cada 10 minuts i uns centenars de comandes al dia: kilobytes, no gigabytes. Contractar un Interconnect per a això seria com llogar un tràiler per portar la compra. Cloud VPN HA, en minuts i per desenes d'euros al mes.

Un apunt sobre quan canviaria: si calgués replicar contínuament una base de dades gran, si el volum superés de manera sostinguda 1-2 Gbps, o si la latència d'internet fos inacceptable per a un procés interactiu. Cap no s'aplica.

Cloud VPN HA (alta disponibilitat) és la versió amb SLA del 99,99 %. La diferència amb la VPN clàssica:

Per aconseguir el 99,99 % calen dos túnels des de les dues interfícies de la passarel·la de Google cap a dos dispositius (o almenys dues IP) de l'altre costat. Amb un sol dispositiu a Sabadell s'aconsegueix 99,9 %, que per a una botiga és més que suficient.

Google assigna dues IP públiques, una per interfície. S'apunten: són les que cal configurar al router de Sabadell.

Google necessita saber com és el dispositiu remot:

--interfaces=0=IP declara un dispositiu. Si a Sabadell hi hagués dos routers, seria 0=IP_A,1=IP_B i s'assoliria el 99,99 %.

• --asn=65001: número de sistema autònom de Google en aquesta sessió BGP. Es fa servir el rang privat 64512-65534.
• --advertisement-mode=custom: control explícit del que s'anuncia. Amb default s'anuncien totes les subxarxes automàticament; custom obliga a decidir, que és el correcte (apartat 11).

Si el router ja existeix pel Cloud NAT de 03-01, es reutilitza: un Cloud Router serveix alhora per a NAT i per a VPN.

• --interface=$I: cada túnel surt per una interfície diferent de la passarel·la. Aquí hi ha la redundància.
• --ike-version=2: IKEv2 sempre. IKEv1 només si l'equip remot és antic.
• --shared-secret: la clau precompartida. Ha de coincidir exactament amb la del router de Sabadell i va a Secret Manager (03-06), mai a un fitxer de Terraform.

Cada túnel necessita la seva sessió BGP, amb IP d'enllaç en un /30 del rang d'enllaç local 169.254.0.0/16:

Adreçament resultant:

--advertised-route-priority més baixa guanya. Amb aquestes prioritats, el túnel 0 és l'actiu i l'1 la reserva; si el 0 cau, BGP convergeix a l'1 en segons. Per a actiu-actiu es posaria la mateixa prioritat als dos i el trànsit es repartiria per ECMP.

La sortida bona té aquest aspecte:

numLearnedRoutes: 1 i 192.168.10.0/24 a learnedRoutes és la prova que funciona. Si el túnel està ESTABLISHED però numLearnedRoutes: 0, el problema no és la VPN: és que l'altre costat no anuncia res per BGP.

Val la pena entendre què està passant, perquè gairebé totes les fallades de connectivitat híbrida són d'encaminament i no del túnel.

BGP (Border Gateway Protocol) és el protocol amb el qual dues xarxes s'expliquen quins destins saben abastar. Cada xarxa té un identificador, l'ASN, i anuncia els seus prefixos.

La diferència amb l'encaminament estàtic és la que justifica tot l'aparell:

El cas que ho fa evident: quan la Marta creï sn-run-euw1 (10.10.20.0/24) per a la VPC directa de Cloud Run, el Cloud Router l'anunciarà automàticament a Sabadell i l'ERP hi podrà respondre sense que ningú toqui el router de la botiga. Amb rutes estàtiques, caldria trucar al proveïdor de la botiga cada vegada.

I el detall que s'oblida: l'encaminament global de l'apartat 4. Amb routing_mode = REGIONAL, un Cloud Router d'europe-west1 només anuncia subxarxes d'europe-west1. Amb GLOBAL, les anuncia totes.

Amb --advertisement-mode=custom es decideix exactament què s'anuncia. Casos habituals:

Sense aquesta línia, Sabadell no pot abastar Cloud SQL per IP privada encara que el túnel funcioni perfectament, perquè 10.10.240.0/20 no és una subxarxa de la VPC: és un rang cedit a Google. És de les fallades més desconcertants que existeixen, perquè tot sembla correcte.

També es pot anunciar només des d'una sessió BGP concreta, útil per a polítiques de sortida:

Quan hi ha moltes xarxes i moltes seus, el problema N² de l'aparellament es torna insuportable. Network Connectivity Center (NCC) ho resol amb un model radial (hub and spoke):

• Un eix (hub) central, que és un recurs lògic.
• Radis (spokes): VPC, túnels VPN, adjunts d'Interconnect, o dispositius virtuals de tercers.
• L'eix encamina entre radis, cosa que dona la transitivitat que l'aparellament no té.

El necessita AlpinaShop? No. Amb una VPC compartida i un enllaç a Sabadell, l'eix no aporta res i costa per radi i hora. S'explica perquè és la resposta correcta quan la xarxa creix —cinc o més xarxes i seus que s'han de parlar entre si— i perquè saber que existeix evita muntar quinze aparellaments a mà.

Aquest apartat respon al risc del principi de la lliçó, i és probablement el més important que hi ha aquí.

El problema que IAM no resol. IAM controla qui pot fer què. No controla des d'on ni cap a on. Si sa-informes-nocturnos té permís per llegir alpinashop_analitica, i algú roba les seves credencials:

IAM autoritza aquesta operació. El permís existeix, la petició és legítima des del punt de vista de l'autorització. I les dades surten.

Els controls de servei de VPC (VPC Service Controls) creen un perímetre al voltant de projectes i serveis. Dins del perímetre es pot treballar; les dades no creuen la frontera, ni tan sols amb credencials vàlides.

Amb --dry-run, el perímetre registra el que bloquejaria sense bloquejar res. Es deixa una o dues setmanes i s'analitzen les violacions:

Només quan el llistat és net o justificat s'aplica de debò (--enable-dry-run-config i promoció del perímetre).

VPC Service Controls és la funció de Google Cloud amb la qual més gent s'ha bloquejat a si mateixa.

El que trenca habitualment, i cal preveure-ho abans:

I hi ha dues regles d'or:

1. Mai activis un perímetre un divendres. És un tòpic i és literalment cert.
2. --dry-run no és opcional. És la diferència entre un control de seguretat i una caiguda d'un dia.

Avís. El disseny de perímetres, nivells d'accés i regles d'entrada i sortida té implicacions directes de seguretat i de compliment normatiu. El d'aquí és un model docent correcte, però abans de protegir dades personals o financeres en producció ho ha de revisar un professional de seguretat i de compliment normatiu.

Network Intelligence Center agrupa les eines que converteixen el diagnòstic de xarxa en una cosa determinista.

Els fets. Dilluns al matí. El procés de sincronització d'estoc porta tres hores fallant: Connection timed out en connectar a 192.168.10.20:3306. El divendres funcionava. Ningú no ha tocat res (diuen).

Pas 1 — Està amunt el túnel?

Els dos túnels amunt. No és la VPN. Aquí s'acaba el diagnòstic de molta gent, que conclou «és cosa de Sabadell» i truca per telèfon.

Pas 2 — Està amunt el BGP i quines rutes hi ha?

Zero rutes apreses. El túnel està establert i la sessió BGP també, però Sabadell ha deixat d'anunciar 192.168.10.0/24. El paquet no sap per on sortir.

Pas 3 — Confirmar-ho amb una prova de connectivitat, que dona un veredicte inapel·lable:

NO_ROUTE. No és el tallafoc, no és el túnel: no hi ha ruta. La prova de connectivitat ha convertit tres hores de sospites en trenta segons de certesa.

Pas 4 — La causa arrel. Trucada a l'empresa que manté el router de Sabadell: el dissabte van actualitzar el microprogramari i la configuració BGP es va restaurar des d'una còpia anterior a la instal·lació de la VPN. La xarxa anunciada va desaparèixer de la configuració.

Pas 5 — Correcció i lliçons. El proveïdor restaura l'anunci; les rutes apareixen en menys d'un minut i el procés torna a funcionar. El que es canvia després:

1. Alerta sobre numLearnedRoutes == 0 a Cloud Monitoring. Hauria avisat el dissabte a la nit.
2. Alerta sobre l'estat dels túnels VPN (vpn/tunnel_established).
3. La sincronització d'estoc deixa de fallar en silenci: si porta més de 30 minuts sense actualitzar, alerta. La detecció la va fer un humà tres hores tard, exactament el que 06-04 volia evitar.
4. L'acord amb el proveïdor de la botiga incorpora avisar de canvis al router.

Els VPC Flow Logs, activats a l'apartat 4 amb mostreig del 50 %, permeten respondre preguntes que cap altra eina no respon:

Serveixen per a tres coses concretes: investigar incidents de seguretat (qui va parlar amb aquella IP?), entendre el cost (quin trànsit creua zones o regions) i trobar trànsit que no hauria d'existir.

El seu inconvenient és el volum: són cars. Per això flow_sampling = 0.5, i per això convé un abocador a BigQuery amb caducitat en lloc de retenció llarga a Cloud Logging (06-06).

Google Cloud ofereix dos nivells de xarxa per al trànsit sortint cap a internet:

La diferència pràctica amb un exemple: un client de Berlín que visita AlpinaShop a europe-west1. Amb Premium, entra a la xarxa de Google a Berlín i la resta del camí va per fibra de Google. Amb Estàndard, tot el trajecte Berlín→Bèlgica va per internet públic, amb la latència i variabilitat que això implica.

Criteri:

AlpinaShop fa servir Premium per a la botiga —no és negociable, el balancejador global ho exigeix— i podria fer servir Estàndard a alpinashop-dev, encara que l'estalvi seria de cèntims.

Aquest apartat és un avançament de 07-05, però pertany aquí perquè són decisions de xarxa.

La regla que resumeix el 90 % dels casos:

L'entrada és gratis. La sortida es paga. I com més lluny, més cara.

Els quatre amagatalls clàssics, amb el seu remei:

1. Trànsit entre zones per alta disponibilitat. Cloud SQL en HA regional replica contínuament entre zones, i això es paga. És el preu de la disponibilitat i està bé pagar-lo — però cal saber que hi és abans de sorprendre's.
2. Aplicació i base de dades en zones diferents sense motiu. Cada consulta creua zona i paga. Col·locar deliberadament el que es parla molt és gratis i estalvia.
3. Registres i mètriques que creuen regions. Un abocador de registres d'europe-west1 cap a un bucket a us-central1 paga trànsit intercontinental per cada línia de registre. Els buckets de registres es posen a la mateixa regió.
4. Còpies de seguretat i exportacions a un altre proveïdor. Treure 500 GB al mes cap a un altre núvol són desenes d'euros mensuals que ningú no va atribuir a ningú.

Les tres palanques d'estalvi que s'apliquen a la xarxa:

• CDN (03-03): cada resposta servida des de memòria cau no surt de l'origen. És la palanca més gran per a un lloc amb imatges.
• Col·locació: posar a la mateixa zona el que es crida constantment.
• Comprimir: gzip o brotli al balancejador redueix els bytes facturats i a més millora l'experiència.

I el desglossament per servei es consulta amb l'exportació de facturació de 01-04:

• No tenir pla d'adreçament. El dia que dos rangs s'encavalquin, l'única solució és renumerar amb aturada de servei. Deu minuts de full de càlcul eviten un cap de setmana horrible.
• Fer servir 172.16.0.0/12 a la VPC. És el rang per defecte de Docker; els contenidors no podran abastar aquelles IP.
• Crear la VPC amb auto_create_subnetworks = true. Crea una subxarxa a cada regió amb rangs que no vas triar i que probablement xocaran amb alguna cosa.
• Posar la xarxa compartida al projecte de producció. Obliga a donar permisos de producció a qui només necessita una subxarxa de desenvolupament. Projecte amfitrió propi i buit.
• Donar compute.networkUser sobre tota la xarxa. Es dona sobre la subxarxa concreta. És la meitat del valor de la VPC compartida.
• Oblidar el permís de l'agent serverless-robot-prod en fer servir Cloud Run amb VPC directa en VPC compartida. Error críptic garantit.
• routing_mode = REGIONAL en una xarxa que creixerà. Canviar-ho després reinicia les sessions BGP.
• Esperar transitivitat de l'aparellament. A↔B i B↔C no donen A↔C. Mai.
• Aparellar sense --export-custom-routes. L'aparellament s'estableix i tot i així no s'arriba a la VPN de l'altre costat.
• No anunciar el rang d'accés a serveis privats. Túnel perfecte i Cloud SQL inabastable des de la seu.
• Muntar la VPN amb un sol túnel. Qualsevol manteniment de l'altre costat és un tall. Dos túnels, sempre.
• Activar VPC Service Controls sense --dry-run. És la manera més eficaç de bloquejar tot el teu equip, tu inclòs.
• Oblidar que Cloud Shell surt per IP de Google. Amb un perímetre actiu, la teva pròpia consola deixa de funcionar i sembla una fallada de la plataforma.
• Diagnosticar xarxes a base de ping i suposicions. Les proves de connectivitat donen un veredicte amb la regla concreta que bloqueja.
• Ignorar el trànsit entre zones. No és gratis, i en arquitectures replicades és una part apreciable de la factura.
• Consell: alerta sobre numLearnedRoutes i sobre l'estat dels túnels. Són dues mètriques que avisen d'una fallada híbrida abans que ho noti un procés de negoci.
• Consell: desa la clau precompartida de la VPN a Secret Manager, no al .tf ni a l'historial del terminal.
• Consell: activa els Flow Logs amb mostreig, no al 100 %. Al 50 % veus el que necessites per la meitat de cost.

AlpinaShop creix i cal planificar la xarxa per al següent:

• Segona regió europe-southwest1 (Madrid) per a alta disponibilitat, amb les mateixes tres subxarxes.
• Dues botigues físiques noves: Girona i Saragossa, cadascuna amb la seva LAN i la seva VPN.
• Un soci logístic que es connectarà per Private Service Connect per consultar l'estat dels enviaments.
• Un entorn de proves de càrrega que es crea i es destrueix, aïllat de la resta.
• Previsió d'un clúster de GKE amb fins a 200 pods.

Elabora la taula completa d'adreçament indicant rang, ús, regió i justificació de la mida. Assenyala quines decisions prens per no quedar-te sense espai en cinc anys i quins rangs prohibeixes explícitament.

Escriu el Terraform que:

1. Converteix alpinashop-red en projecte amfitrió i vincula alpinashop-prod, alpinashop-dev i alpinashop-datos.
2. Crea les subxarxes sn-web-euw1, sn-datos-euw1 i sn-dev-euw1 amb Private Google Access i Flow Logs al 50 %.
3. Concedeix permisos de manera que: gcp-desarrollo@ només pugui fer servir sn-dev-euw1; gcp-datos@ només sn-datos-euw1; el compte de servei de Cloud Run pugui fer servir sn-web-euw1; i ningú tret de gcp-infra@ pugui modificar regles de tallafoc.
4. Defineix qui té compute.xpnAdmin i en quin nivell de la jerarquia.

Explica a més què passaria si el Dani intentés crear una VM a sn-datos-euw1 i quin error veuria exactament.

Per a cadascun d'aquests tres casos, indica el diagnòstic més probable, com el confirmaries amb eines concretes, i com el corregiries.

(a) El servei alpinashop-web a Cloud Run, amb VPC directa configurada, no aconsegueix connectar a 192.168.10.20:3306 (l'ERP). Des d'una VM de sn-web-euw1 sí que funciona. Els túnels estan ESTABLISHED i el BGP aprèn 192.168.10.0/24.

(b) La Lucía no pot obrir la consola de BigQuery des del seu portàtil a casa. Des de l'oficina sí. L'error diu VPC Service Controls: Request is prohibited by organization's policy. Fa dues setmanes que el perímetre està actiu i fins ara ningú no s'havia queixat.

(c) Una VM del projecte alpinashop-datos (VPC pròpia, aparellada amb alpinashop-vpc) necessita arribar a l'ERP de Sabadell. L'aparellament està ACTIVE, la VM arriba sense problemes a les VM de sn-web-euw1, però a 192.168.10.20 no.

Solució 1 — Dissenyar l'adreçament d'una expansió

Principi rector: reservar blocs /16 complets per àmbit encara que se'n faci servir una fracció mínima. L'espai privat té 16,7 milions d'adreces a 10.0.0.0/8: estalviar rangs és una falsa economia i la causa número u de renumeracions.

Les cinc decisions que eviten la renumeració a cinc anys:

1. Un /16 per regió, amb el segon octet com a identificador de regió. 10.X0.0.0/16. Mirar una IP i saber la regió sense consultar res té un valor operatiu enorme durant un incident.
2. Esquema de subxarxes idèntic entre regions, canviant només el segon octet. Les regles de tallafoc, els scripts i els diagrames es repliquen amb una substitució.
3. Les botigues van totes a 192.168.0.0/16 amb /24 correlatius. L'anunci BGP es pot agregar i una regla de tallafoc cobreix totes les botigues presents i futures.
4. Les proves de càrrega a 10.100.0.0/16, fora del bloc de producció i en VPC pròpia sense aparellar. Si un test descontrolat inunda alguna cosa, no pot abastar producció. I com que és efímer, el seu rang es pot reutilitzar sense risc.
5. Reservar 10.0.0.0/16 i 10.1.0.0/16 sense fer-los servir. Són els rangs que tria per defecte qui no planifica. El dia que AlpinaShop compri una altra empresa, és gairebé segur que la comprada fa servir un d'aquests dos — i tenir-los lliures evita renumerar la xarxa aliena.

Sobre el soci logístic: no consumeix adreçament propi. Amb PSC crea un extrem a la seva VPC amb el seu rang, apuntant al service attachment d'AlpinaShop. Cap de les dues parts no veu la xarxa de l'altra, no hi ha risc d'encavalcament i no hi ha rutes per gestionar. És exactament el cas d'ús de PSC davant de l'aparellament, i per això s'ha convertit en l'estàndard per connectar amb socis.

Solució 2 — Implementar la VPC compartida amb permisos correctes

Sobre compute.xpnAdmin. Es concedeix a gcp-infra@ a nivell de la carpeta compartido, no de projecte, perquè és on viu l'amfitrió i des d'on es vinculen els projectes. Concedir-lo a nivell d'organització donaria poder per convertir en amfitrió qualsevol projecte de l'empresa, que és més del que cal. Aplicant el mínim privilegi de 03-04: el nivell més baix de la jerarquia en què el permís funciona.

A AlpinaShop, gcp-infra@ és la Marta, i aquest és exactament el tipus de permís que a 07-04 es convertirà en candidat a elevació temporal en lloc de permanent.

Què passaria si el Dani intentés crear una VM a sn-datos-euw1:

El permís que falta és compute.subnetworks.use, que forma part de roles/compute.networkUser. El missatge anomena la subxarxa concreta, cosa que fa el diagnòstic immediat.

I hi ha un matís revelador: si el Dani executa gcloud compute networks subnets list --project=alpinashop-red, veurà sn-dev-euw1 i també sn-datos-euw1, perquè té networkViewer. Pot veure que existeix, però no fer-la servir. Aquesta distinció entre veure i usar és deliberada: sense visibilitat no es pot diagnosticar res, i amb networkViewer no es pot fer mal.

Solució 3 — Diagnosticar tres fallades de connectivitat

(a) Cloud Run no arriba a l'ERP, però una VM de la mateixa subxarxa sí.

Diagnòstic. Que una VM de sn-web-euw1 sí que hi arribi demostra que la ruta, el BGP i el tallafoc estan bé. El que canvia entre la VM i Cloud Run és com surt el trànsit. La causa gairebé segura és --vpc-egress: si està en private-ranges-only, el trànsit a rangs RFC 1918 hauria d'anar per la VPC… i 192.168.10.0/24 és RFC 1918, així que això encaixa. Queden dues hipòtesis:

1. El servei no té VPC directa realment aplicada (es va configurar al servei però la revisió en trànsit és anterior al canvi). És la causa més freqüent: la configuració de xarxa s'aplica per revisió, i si es va canviar amb --no-traffic, el 100 % del trànsit continua a la revisió antiga sense xarxa.
2. La subxarxa assignada a la VPC directa no és sn-web-euw1 sinó una altra sense les rutes correctes.

Confirmació.

Correcció. Redesplegar aplicant xarxa i donant trànsit a aquella revisió:

I comprovar que l'agent serverless-robot-prod té networkUser sobre sn-web-euw1; sense ell, el desplegament hauria fallat amb un error de permisos poc explícit.

(b) La Lucía no pot entrar a BigQuery des de casa.

Diagnòstic. El missatge ho diu literalment: el perímetre de VPC Service Controls està bloquejant la petició. El nivell d'accés acceso_corporativo inclou 88.20.145.0/24 (l'oficina) i 192.168.10.0/24 (Sabadell), però no la IP domèstica de la Lucía. Des de l'oficina funciona perquè surt pel rang permès.

Que «fins ara ningú no s'havia queixat» no significa que sigui nou: significa que ningú no havia treballat des de fora des que es va activar el perímetre. És el patró típic — el perímetre s'activa, funciona, i dues setmanes després algú teletreballa i apareix el problema.

Confirmació.

El camp callerIp mostra la IP domèstica i violationReason dirà NO_MATCHING_ACCESS_LEVEL.

Correcció. Hi ha tres opcions, i la pitjor és la més temptadora:

La tercera és més feina inicial i és l'única que escala: el control deixa de ser «des d'on et connectes» i passa a ser «quin dispositiu ets i qui ets», que és el que realment importa. Mentre s'implanta, l'opció 2 és un pont raonable.

(c) La VM d'alpinashop-datos arriba a sn-web-euw1 però no a Sabadell.

Diagnòstic. És el problema de transitivitat de l'aparellament, en la seva forma més pura. La VPC de dades està aparellada amb alpinashop-vpc, i per això abasta les seves subxarxes. Però la ruta cap a 192.168.10.0/24 no és una subxarxa d'alpinashop-vpc: és una ruta apresa per BGP des del túnel VPN. I per defecte l'aparellament no exporta rutes apreses per BGP ni rutes estàtiques: només les de les subxarxes.

A més, encara que s'exportessin, hi ha un segon obstacle: l'aparellament no és transitiu, de manera que el trànsit de retorn des de Sabadell tampoc no sabria com tornar a la VPC de dades tret que el seu rang també s'anunciï per BGP.

Confirmació.

192.168.10.0/24 no apareixerà a la llista.

Correcció. Hi ha dos camins, i la diferència entre ells és la moralitat de la lliçó:

Camí 1 — Apedaçar l'aparellament. Activar l'exportació de rutes personalitzades al costat d'alpinashop-vpc i la importació al costat de dades, i a més anunciar per BGP el rang de la VPC de dades cap a Sabadell:

Funciona, però deixa una topologia que cal recordar i documentar, i que es trencarà la propera vegada que algú afegeixi una xarxa.

Camí 2 — La solució correcta: eliminar l'aparellament. alpinashop-datos és un projecte propi d'AlpinaShop, a la mateixa organització. No hauria de tenir VPC pròpia aparellada: hauria de ser un projecte de servei de la VPC compartida. Tan bon punt ho sigui, els seus recursos seran a alpinashop-vpc, veuran les rutes de la VPN com qualsevol altre recurs, i el problema desapareix sense configurar res.

Aquesta és la lliçó de l'exercici, i de l'apartat 6: l'aparellament es fa servir quan l'altra xarxa és d'algú altre. Aparellar xarxes pròpies dins de la mateixa organització crea feina permanent per resoldre problemes que la VPC compartida no té. Si et trobes exportant rutes personalitzades entre dues VPC teves, és que vas triar l'eina equivocada.

La xarxa d'AlpinaShop ha passat de ser una VPC en un projecte a ser una plataforma de xarxa dissenyada.

Saps reconèixer quan una VPC deixa de bastar pels seus set senyals, i saps que el primer —abans de tocar res— és el pla d'adreçament, amb la seva regla inviolable: dos rangs que puguin arribar a connectar-se alguna vegada no es poden encavalcar. Amb les decisions que el fan durador: un /16 per regió amb el segon octet com a identificador, esquema idèntic entre regions, reserves per al que encara no existeix, i rangs prohibits explícitament —172.16.0.0/12 per Docker, 169.254.0.0/16 per BGP, i els «obvis» reservats per al dia que compris una empresa.

Domines la VPC compartida: projecte amfitrió propi i gairebé buit a la carpeta compartido, projectes de servei que aporten còmput i facturació, i els dos rols que la governen — compute.xpnAdmin per vincular projectes, concedit a la carpeta i no a l'organització, i compute.networkUser concedit sobre la subxarxa concreta, que és on hi ha la meitat del valor del model. Amb el permís de l'agent serverless-robot-prod que ningú no endevina, i amb la veritat incòmoda que una VM no es migra de xarxa: es recrea.

Distingeixes l'aparellament amb les seves tres limitacions —no és transitiu, els rangs no es poden encavalcar, les quotes s'agreguen— i saps que --export-custom-routes està desactivat per defecte i és la causa número u de «està aparellat però no hi arribo». Tens la taula de decisió amb la seva regla: projectes meus i una sola xarxa per governar → compartida; xarxa d'algú altre → aparellament; més de cinc xarxes i seus → Network Connectivity Center i la seva topologia radial.

Coneixes Private Service Connect en els seus tres usos: extrems amb IP teva cap a les API de Google —que a diferència de Private Google Access sí que funcionen des de l'altre costat del túnel—, consum de serveis de tercers sense compartir xarxes ni rangs, i publicació dels teus. I saps per què ha substituït l'aparellament com a forma estàndard de connectar amb socis.

Has connectat la botiga de Sabadell de debò: la taula de les tres opcions híbrides amb amplada de banda, latència, SLA, cost i termini, l'elecció raonada de Cloud VPN HA per a kilobytes d'estoc, i la implementació completa —passarel·la amb dues interfícies, passarel·la externa, Cloud Router amb ASN, dos túnels amb IKEv2 i secret a Secret Manager, dues sessions BGP amb prioritats 100 i 200, tallafoc i verificació—. Entens el BGP de debò: ASN, rutes anunciades i apreses, prioritats, i per què el dinàmic guanya a l'estàtic tan bon punt hi ha més d'una subxarxa. I saps que numLearnedRoutes: 0 amb el túnel ESTABLISHED significa que el problema no és teu.

Saps governar l'anunci de rutes amb --advertisement-mode=custom, inclòs el rang d'accés a serveis privats sense el qual Cloud SQL és inabastable des de la seu encara que tot sembli correcte, i coneixes els cinc errors clàssics d'encaminament amb el seu símptoma i el seu remei.

Has aixecat un perímetre de VPC Service Controls que respon al risc real: unes credencials filtrades ja no poden treure les dades, perquè IAM autoritza però el perímetre no deixa creuar la frontera. Amb nivells d'accés, --dry-run com a pas no negociable, la taula del que es trenca habitualment, i l'advertiment doble: mai un divendres, i que ho revisi un professional de seguretat i compliment abans de producció.

Saps diagnosticar en lloc de suposar: proves de connectivitat que retornen NO_ROUTE amb la causa exacta, topologia, analitzador de tallafoc i Flow Logs amb mostreig. Has seguit una fallada real de principi a fi —túnel amunt, BGP amunt, zero rutes apreses, microprogramari restaurat a Sabadell— i has vist el que es canvia després: alertes sobre numLearnedRoutes, sobre l'estat dels túnels, i sobre la frescor de l'estoc, perquè la detecció la continuava fent un humà tres hores tard.

I coneixes els nivells Premium i Estàndard, i sobretot on s'amaga la factura del trànsit: l'entrada és gratis, la sortida es paga, i el trànsit entre zones —que gairebé ningú no mira— apareix tan bon punt hi ha alta disponibilitat. Amb els quatre amagatalls clàssics i les tres palanques: CDN, col·locació i compressió.

Aquest últim apartat és el pont. Aquesta lliçó ha deixat veure una part de la factura que ningú no estava mirant, i no és l'única: han passat set mòduls afegint serveis —VM, buckets, BigQuery, Dataflow, un clúster, endpoints de Vertex AI, registres, traces, ara túnels i Flow Logs— i ningú no ha obert la factura sencera i l'ha entesa línia a línia.

Abans d'això queda una cosa amb més urgència. S'ha construït seguretat a cada mòdul: tallafoc a 03-01, WAF a 03-05, IAM a 03-04, secrets i CMEK a 03-06, TLS a 03-07, ara perímetres. Però mai no s'ha mirat el conjunt. La lliçó següent fa just això: revisa la seguretat d'AlpinaShop capa per capa, de la identitat a la detecció, i escriu honestament el deute que queda.