Hi ha un problema que arrossegues des de 06-03 sense resoldre'l del tot. PostgreSQL escolta a 10.0.2.15:5432 i ufw només ho permet des de 10.0.2.0/24, cosa que està bé mentre siguis dins d'aquella xarxa. El tauler d'estadístiques d'HAProxy de 07-07 té la mateixa restricció. I quan la Marta necessita mirar un informe des de casa, o quan tu has de diagnosticar alguna cosa un diumenge, l'única via és SSH al servidor i treballar des d'allà — cosa que funciona, però no escala i no serveix per a una eina gràfica.

La temptació evident és obrir el 5432 al món amb una contrasenya forta. És exactament el que no es fa: exposaries el motor de base de dades als escàners automàtics que recorren Internet, i el dia que aparegui una vulnerabilitat d'autenticació a PostgreSQL —n'han aparegut— la teva base de dades sencera estaria en joc mentre apliques el pedaç.

Aquesta lliçó munta l'alternativa correcta: una VPN amb WireGuard. En acabar, la xarxa interna serà abastable des de qualsevol lloc amb un sol port UDP obert, PostgreSQL i el tauler d'estadístiques quedaran tancats a l'exterior, i tindràs el mateix mecanisme a punt per arribar al servidor multimèdia de 08-03 des d'un hotel.

1. Què resol una VPN i què no
2. Casos d'ús i quin necessita Tramontana
3. WireGuard enfront d'OpenVPN i IPsec
4. Com funciona WireGuard: interfície, parells i encaminament criptogràfic
5. AllowedIPs: encaminament i control d'accés alhora
6. Instal·lació i generació de claus
7. Configuració del servidor
8. Configuració dels clients: portàtil i mòbil
9. Encaminament, NAT i túnel dividit enfront de túnel complet
10. DNS dins del túnel
11. Integració amb el tallafocs i tancament de ports
12. Verificació
13. Gestió de clients: alta, baixa i rotació
14. Seguretat: el que protegeix i el que no
15. Automatització amb Ansible
16. Operació i problemes habituals

Una xarxa privada virtual crea un túnel xifrat entre dos punts de manera que el trànsit que hi circula per dins és indesxifrable i inalterable per a qui l'observi des de fora, i els extrems apareixen com si estiguessin a la mateixa xarxa local.

Això és tot el que fa. I convé enunciar-ho amb precisió perquè el màrqueting de les VPN comercials ha creat un núvol d'expectatives falses:

Les dues files més importants de la dreta:

«No xifra més enllà del servidor VPN.» El trànsit va xifrat del portàtil de la Marta al servidor. A partir d'aquí surt com qualsevol altre trànsit. Si va a PostgreSQL sense TLS, viatja en clar per la xarxa interna. La VPN trasllada el punt de confiança, no l'elimina — i per això a 08-02 vas configurar hostssl per a la rèplica.

«No converteix una xarxa interna en segura.» És l'error conceptual amb pitjors conseqüències, i hi tornarem a l'apartat 14.

Tramontana necessita el primer: accés remot. L'objectiu concret i acotat:

• Que la Marta arribi al tauler d'estadístiques d'HAProxy i als informes des de casa.
• Que tu arribis a PostgreSQL a 10.0.2.15:5432 amb una eina gràfica, sense exposar-lo.
• Que l'accés SSH deixi de dependre de tenir el port 22 publicat a Internet.
• Que, en conseqüència, es puguin tancar el 5432 i el 8404 a l'exterior.

El que no cal: unir seus (només n'hi ha una), ni sortida per una altra IP (ningú no ho necessita, i muntar-ho obligaria a encaminar tot el trànsit personal de la Marta pel servidor de l'empresa, cosa que a més té implicacions de privadesa que no volem).

L'elecció és WireGuard, i les raons per ordre de pes:

1. Les 4.000 línies de codi no són una curiositat: són la raó que es pugui auditar de debò i que la superfície d'atac sigui minúscula. OpenVPN i IPsec han tingut vulnerabilitats greus; amb vint-i-cinc vegades menys codi, hi ha vint-i-cinc vegades menys llocs on amagar-les.
2. La criptografia no és configurable, i això és un avantatge. No hi ha negociació d'algorismes, no hi ha conjunts febles per desactivar, no hi ha atacs de degradació. La majoria de les VPN insegures del món no ho són per una fallada del programari, sinó per una configuració mal feta; WireGuard elimina aquella categoria sencera d'errors.
3. Corre al nucli, sense copiar cada paquet a espai d'usuari. En un servidor de 2 vCPU, la diferència es nota.
4. La configuració cap en una pantalla i s'entén sencera, cosa que fa que es pugui revisar.

I les dues raons honestes per triar una altra cosa:

• Si necessites usuari, contrasenya i segon factor, WireGuard no ho fa: autentica per clau pública, punt. Existeixen capes per sobre, però no és natiu. En una empresa amb cent empleats i rotació, OpenVPN amb LDAP i TOTP pot ser millor.
• Si la xarxa de destinació bloqueja UDP —algunes xarxes corporatives i d'hotels només deixen sortir el 80 i el 443 per TCP—, WireGuard senzillament no connectarà. OpenVPN sobre TCP/443 passa per gairebé qualsevol lloc disfressat d'HTTPS.

Per a Tramontana, amb dues o tres persones de confiança i control sobre els dispositius, WireGuard és clarament l'opció correcta.

Aquí hi ha els tres conceptes que fan que WireGuard s'entengui o no s'entengui. Mereixen llegir-se a poc a poc.

OpenVPN és un dimoni que corre, es configura, arrenca, s'atura i manté connexions. WireGuard no és un dimoni: és un tipus d'interfície de xarxa del nucli, com eth0 o com una interfície VLAN.

Les conseqüències pràctiques són grans:

• Es configura amb ip i amb wg, les eines de xarxa de sempre.
• L'encaminament és l'encaminament normal de Linux: ip route, taules, mètriques. El de 06-01 s'hi aplica tal qual.
• El tallafocs la tracta com qualsevol altra interfície: les regles de nftables de 06-03 hi funcionen igual.
• No hi ha «servidor» ni «client» al protocol. Tots dos extrems són parells (peers) idèntics. El que anomenem servidor és simplement el parell que té IP pública fixa i no especifica l'Endpoint dels altres.

No hi ha autoritat certificadora, ni certificats, ni llistes de revocació, ni PKI. Cada dispositiu genera un parell de claus Curve25519. Perquè dos dispositius parlin, cadascun necessita la clau pública de l'altre. Això és tota la gestió d'identitat.

Aquí hi ha la idea que fa WireGuard diferent de tota la resta. En una VPN clàssica hi ha dos mecanismes separats: un decideix per on va un paquet (encaminament) i un altre decideix si es permet (control d'accés). WireGuard els fusiona en un de sol.

Cada parell té associada una llista d'adreces IP: AllowedIPs. I aquella llista es fa servir en totes dues direccions, amb dos significats diferents:

Llegit en paraules:

• En enviar, AllowedIPs funciona com una taula de rutes: el paquet es xifra amb la clau del parell la llista del qual contingui la IP de destinació.
• En rebre, AllowedIPs funciona com un filtre antisuplantació: un paquet desxifrat correctament amb la clau de luis la IP d'origen del qual no sigui als AllowedIPs de luis es descarta.

Aquella segona part és el que fa WireGuard segur per disseny. Encara que el portàtil del Luis estigui compromès i la seva clau privada robada, l'atacant no pot enviar paquets fingint ser 10.8.0.99 ni 10.0.2.15: la criptografia i l'encaminament estan lligats, i el nucli descarta el paquet abans que arribi enlloc.

WireGuard no té «connectar» ni «desconnectar». La interfície existeix o no existeix. Quan hi ha un paquet per enviar, WireGuard fa una salutació d'un viatge d'anada i tornada —si no l'ha feta en els últims dos minuts— i l'envia. Si no hi ha trànsit, no hi ha paquets.

Això té tres conseqüències molt pràctiques:

• Canviar de xarxa no talla res. Un mòbil que passa de Wi-Fi a 5G continua funcionant: WireGuard detecta el canvi d'origen al següent paquet vàlid i actualitza l'extrem automàticament (roaming).
• Un parell inactiu és indistingible d'un d'apagat. wg show indica quan va ser l'última salutació, no si està «connectat».
• WireGuard és silenciós davant de qui no té claus. Un paquet que no es desxifra correctament es descarta sense respondre res. Per a un escàner de ports, el port UDP de WireGuard és indistingible d'un port tancat. Aquella propietat, per si sola, ja justifica preferir-lo a exposar serveis.

El mòdul és dins del nucli des de la versió 5.6, així que a Ubuntu 24.04 amb el nucli 6.8 no hi ha res per compilar.

Les tres ordres mereixen una nota: wg genkey genera una clau privada Curve25519 en base64; wg pubkey deriva la pública llegint la privada de l'entrada estàndard; wg genpsk genera 32 bytes aleatoris per a la clau precompartida. La derivació és d'un sol sentit: de la pública no es pot tornar a la privada.

La clau privada del servidor no surt mai del servidor. La clau privada de cada client no surt mai del client. Això significa que, idealment, és el client qui genera el seu parell i t'envia només la pública. A la pràctica, per a un mòbil, se sol generar al servidor i transferir-se per QR; és un compromís acceptable si la transferència és directa i el fitxer s'esborra després.

Abans d'escriure res, cal decidir el rang de la VPN. Ha de no encavalcar-se amb cap xarxa que els clients puguin fer servir:

Aquell 10.0.0.0/24 de l'última fila és una trampa real: és el rang per defecte de molts routers, i si un client és en una xarxa 10.0.2.0/24 —la mateixa que la interna de Tramontana— tindrà un conflicte de rutes irresoluble. Triar rangs poc freqüents per a la infraestructura pròpia evita aquell problema per sempre.

Quatre detalls d'aquella configuració que convé entendre:

Address = 10.8.0.1/24, amb /24 i no /32. La màscara determina la ruta que wg-quick afegeix automàticament: amb /24, tot 10.8.0.0/24 s'encamina per wg0. Amb /32 caldria afegir les rutes a mà.

Les regles van en una taula inet wg pròpia. És l'aplicació del que vas aprendre a 06-03: una taula separada s'elimina d'un cop amb nft delete table i no interfereix amb les regles que gestiona ufw. L'alternativa —afegir regles a la taula existent— deixa restes acumulades cada vegada que es reinicia la interfície.

La clau privada es llegeix d'un fitxer amb PostUp. Posar-la directament a wg0.conf funciona igual, però barreja secret i configuració en un sol fitxer, cosa que complica gestionar-lo amb Ansible sense no_log a tot arreu. Separar-los permet versionar la configuració i tractar la clau a part.

AllowedIPs = 10.8.0.2/32 per a cada client, amb /32. És el correcte i és on més gent s'equivoca. Vegeu l'apartat 9.

Les aplicacions oficials de WireGuard per a Android i iOS llegeixen la configuració des d'un QR, cosa que evita teclejar quaranta-quatre caràcters en base64 tres vegades:

Advertiment important sobre el QR: conté la clau privada en clar. No s'envia per correu, ni per WhatsApp, ni es deixa a /tmp. Es mostra al terminal, s'escaneja davant del mòbil, i s'esborra:

Un QR de WireGuard fotografiat per damunt de l'espatlla és accés complet a la xarxa interna.

A l'aplicació mòbil convé activar a més «VPN a demanda» excloent-hi la xarxa Wi-Fi de l'oficina: així el túnel s'aixeca automàticament fora i no molesta a dins.

Per defecte, Linux no reenvia paquets entre interfícies: és una màquina, no un router. Perquè el trànsit que arriba per wg0 surti cap a 10.0.2.0/24 cal activar-ho:

L'IPv6 es deixa desactivat deliberadament: si no el fas servir, activar-lo obre un camí que no estàs vigilant. És la mateixa lògica de 06-06.

La Marta, des de 10.8.0.3, consulta PostgreSQL a 10.0.2.15. Sense NAT, el paquet arriba a PostgreSQL amb origen 10.8.0.3, PostgreSQL respon a 10.8.0.3... i la seva taula de rutes no sap on és aquella xarxa, així que envia la resposta a la passarel·la per defecte i es perd.

Hi ha dues solucions:

A Tramontana, amb tot dins de 10.0.2.0/24 i el servidor VPN sent la mateixa màquina, l'emmascarament simplifica i el cost és acceptable. En una xarxa més gran, la ruta estàtica al router és millor: permet que pg_hba.conf distingeixi la Marta del Luis per la seva IP de VPN, i que els registres d'accés siguin útils.

És la decisió de disseny amb més conseqüències de tota la lliçó, i es pren amb una sola línia: AllowedIPs al client.

Per a Tramontana la decisió és el túnel dividit, i amb tres arguments:

1. Amplada de banda. Tot el trànsit de tres persones passant per un servidor de 2 vCPU amb una connexió compartida degradaria la navegació de tothom i competiria amb l'aplicació de reserves, que és el que dona de menjar.
2. Privadesa. Amb túnel complet, tota la navegació personal de la Marta —inclosa la que fa fora d'hores al seu portàtil d'empresa— passa per un servidor de l'empresa i apareix als seus registres. Això té implicacions de protecció de dades i, sobretot, no és necessari per a l'objectiu.
3. L'objectiu és accedir al que és intern, no protegir la navegació general. Per a això hi ha HTTPS i el sentit comú a les xarxes públiques.

Quan sí el túnel complet: un portàtil corporatiu que ha de complir la política de filtratge de l'empresa sigui on sigui, o algú que treballa habitualment des de xarxes que no són de fiar i necessita que tot vagi xifrat. En aquell cas, AllowedIPs = 0.0.0.0/0 al client, i les regles d'emmascarament del servidor ja ho admeten tal com estan escrites.

Amb túnel dividit apareix un detall fàcil de passar per alt: els noms interns.

La directiva DNS = 10.0.2.15 del client fa que wg-quick configuri el resolutor mentre el túnel està actiu. A Ubuntu amb systemd-resolved, wg-quick fa servir resolvectl i fa una cosa elegant:

Amb ~tramontana.example com a domini de cerca, només les consultes d'aquell domini anirien al DNS intern i la resta continuaria pel DNS normal — el que s'anomena DNS dividit i és l'ideal amb túnel dividit:

La fuita de DNS és el problema simètric: si el client continua fent servir el DNS de l'hotel per a tot, aquell servidor veu quins noms interns consultes, cosa que revela informació sobre la teva infraestructura. Comprovar-ho:

Requisit previ, és clar: que hi hagi un DNS intern que resolgui aquells noms. Amb tres màquines, dnsmasq a srv-tramontana basta i sobra.

Aquest és l'apartat on la VPN paga el seu cost, tancant ports que feia temps que estaven oberts des del Mòdul 6.

I ara la part important. Abans de tancar res, cal verificar que la VPN funciona — és literalment el cas de «no tanquis mai la porta per la qual estàs entrant»:

Aquella última decisió mereix defensar-se, perquè la temptació de tancar el 22 és forta. No es tanca SSH fins a tenir una segona via d'accés provada. Si WireGuard falla després d'una actualització del nucli, o si la configuració es corromp, o si el mòdul no carrega, el 22 obert amb LIMIT i fail2ban és la diferència entre un ensurt i un desplaçament físic al centre de dades. És exactament la lliçó de 06-02.

Resultat final:

Què ha canviat, i és el resum del projecte:

Com es llegeix wg show, que és l'eina principal de diagnòstic:

La comprovació 6 és la que demostra el valor de tot el muntatge: dues captures de la mateixa comunicació, una d'il·legible a la xarxa pública i una altra de llegible dins del túnel. És el que cal ensenyar quan algú pregunta què fa exactament una VPN.

I la 7 és la que confirma la decisió de túnel dividit: la navegació normal de la Marta continua sortint per la seva connexió, com ha de ser.

La línia clau és wg syncconf: aplica els canvis sense abaixar la interfície, de manera que donar d'alta un client nou no talla els que estan connectats. Amb wg-quick down && wg-quick up es tallarien tots, i és un error freqüent.

Per què n'hi ha prou amb treure el parell, i és un avantatge arquitectònic de WireGuard: no hi ha llista de revocació, ni certificats que continuïn sent vàlids, ni finestra de caducitat. El servidor només accepta paquets de claus públiques que siguin a la seva configuració. Així que la clau desapareix, aquell dispositiu és indistingible de qualsevol desconegut d'Internet: els seus paquets es descarten sense resposta.

Compara-ho amb OpenVPN, on revocar un certificat exigeix actualitzar la CRL, assegurar-se que el servidor la llegeix, i que no hi hagi sessions actives. Aquí és una ordre que fa efecte al següent paquet.

La rotació de la clau del servidor és l'operació disruptiva, perquè la seva clau pública és a la configuració de tots els clients. El procediment sense talls: aixecar una segona interfície wg1 en un altre port amb la clau nova, migrar els clients un a un, i retirar wg0 quan l'últim hagi migrat.

És el principi bàsic, i té una implicació operativa concreta: el correcte és que el client generi el seu propi parell i t'enviï únicament la clau pública. La clau pública es pot enviar per correu sense cap problema.

L'script alta_vpn.sh genera el parell al servidor perquè per a un mòbil és el pràctic. És un compromís conscient, i per això l'script insisteix a esborrar el fitxer després de lliurar-lo.

És una capa de xifratge simètric de 256 bits que es barreja en la derivació de claus, a més de l'intercanvi Curve25519.

Contra què protegeix, que és una amenaça futura i no actual: un ordinador quàntic prou gran podria trencar Curve25519 mitjançant l'algorisme de Shor. No existeix avui, ni hi és a prop, però existeix un model d'amenaça anomenat «collir ara, desxifrar després»: un adversari amb recursos captura i emmagatzema trànsit xifrat avui per desxifrar-lo d'aquí a quinze anys. La clau precompartida, en ser simètrica, és resistent a aquell atac —Grover només redueix la seguretat efectiva de 256 a 128 bits, cosa que continua sent inabastable.

Contra què no protegeix: res del que passi avui. No afegeix seguretat davant d'atacants clàssics. És una pòlissa barata contra un risc llunyà, i per això és a la configuració: costa una línia.

Una VPN no converteix una xarxa interna en una xarxa segura.

És la conclusió més important de la lliçó, i la més ignorada. Amb la VPN muntada, qualsevol que arribi pel túnel és dins de 10.0.2.0/24 i veu tot el que veu una màquina d'aquella xarxa. Si el portàtil del Luis s'infecta amb un troià, aquell troià té accés directe a PostgreSQL, al tauler d'estadístiques i a qualsevol servei que confiï en la xarxa interna.

El que se'n segueix, d'aquella taula, és l'arquitectura de confiança zero: cada servei autentica i xifra pel seu compte, sense confiar en la xarxa. A la pràctica, per a Tramontana, significa que la VPN no substitueix res del que ja tens: pg_hba.conf continua exigint scram-sha-256, el tauler d'estadístiques continua necessitant la seva restricció, SSH continua amb claus i fail2ban, i TLS continua fent falta a dins. La VPN és una capa més, no un perímetre que permeti relaxar les altres.

I una restricció addicional que la VPN sí que permet fer bé, aprofitant AllowedIPs com a control d'accés:

Com que cada parell té una IP fixa garantida pel mateix protocol —recorda: AllowedIPs impedeix suplantar-la—, aquesta regla és fiable d'una manera que no ho seria en una xarxa normal.

Les claus públiques i precompartides viuen a Vault, integrat amb pass segons 07-06:

Dos detalls d'aquest rol que resumeixen el que vas aprendre a 07-06: el creates: que impedeix regenerar la clau del servidor a cada execució —cosa que deixaria fora tots els clients de cop—, i el handler amb wg syncconf en lloc de reiniciar, que és la versió WireGuard del reload en comptes de restart de 08-01.

1. AllowedIPs encavalcats — l'error més comú i el més desconcertant.

WireGuard resol l'encaminament pel prefix més específic, igual que la taula de rutes. Amb aquella configuració, el trànsit a 10.8.0.3 va a la Marta (més específic), però el Luis pot enviar paquets falsificant qualsevol IP de 10.8.0.0/24, perquè el seu filtre d'entrada l'hi permet. És una bretxa de seguretat, no només un problema d'encaminament.

Pitjor encara: AllowedIPs = 0.0.0.0/0 en un parell del servidor significa «tot el trànsit d'Internet va per aquest parell». És correcte a la configuració d'un client amb túnel complet i catastròfic a la del servidor: en trenca tota la connectivitat.

Regla: al servidor, cada client porta només el seu /32. 0.0.0.0/0 només apareix a la configuració del client, mai a la del servidor.

2. La salutació no passa mai.

Per ordre de probabilitat: el port UDP no hi arriba (tallafocs del servidor, del router, o del proveïdor del client); les claus no es corresponen (la pública del client al servidor no deriva de la seva privada); l'Endpoint és incorrecte o el DNS no resol; o hi ha una PresharedKey en un costat i no a l'altre.

3. Salutació correcta però no hi ha trànsit. El túnel està muntat i no passa res. Gairebé sempre és una de tres: falta net.ipv4.ip_forward=1, falta la regla d'emmascarament, o falta la xarxa de destinació als AllowedIPs del client.

4. Es talla després d'uns minuts d'inactivitat. És NAT: el router del client o l'operadora mòbil oblida l'associació. Solució: PersistentKeepalive = 25 al client.

5. Fragmentació i MTU. El símptoma és característic i enganyós: ping funciona, SSH connecta i es penja en llistar un directori gran, les pàgines web carreguen a mitges.

• Posar AllowedIPs = 0.0.0.0/0 en un parell del servidor. En trenca tota la connectivitat. Allà hi va només el /32 del client.
• AllowedIPs encavalcats entre parells. No és només un problema de rutes: permet que un client suplanti les IP d'un altre.
• Triar 192.168.1.0/24 o 10.0.0.0/24 per a la VPN. Xocarà amb la xarxa de casa d'algú o d'un hotel, i el conflicte no té arranjament des del teu costat.
• Enviar el QR o el fitxer de configuració per correu o missatgeria. Conté la clau privada en clar: és accés complet a la xarxa interna.
• Generar les claus sense umask 077. Neixen amb permisos 644, encara que sigui un instant.
• Tancar el port SSH el mateix dia que muntes la VPN. Si WireGuard falla després d'actualitzar el nucli, et quedes fora. Segona via provada primer.
• Oblidar net.ipv4.ip_forward=1. El túnel es munta perfectament i no passa ni un sol paquet cap a la xarxa interna.
• Oblidar PersistentKeepalive en mòbils. El túnel «cau» al cap de pocs minuts d'inactivitat.
• Fer servir wg-quick down && up per afegir un client. Talla tots els connectats, inclòs tu si administres per la VPN. Fes servir wg syncconf.
• Regenerar la clau del servidor a cada execució d'Ansible. Deixa fora tots els clients de cop. creates: o stat abans.
• Creure que la VPN fa segura la xarxa interna. Un portàtil infectat entra pel túnel amb tots els permisos. Cada servei autentica pel seu compte.
• Treure el TLS dels serveis interns «perquè ja va per la VPN». El xifratge acaba al servidor VPN, no al servei.
• Diagnosticar sense tcpdump. Veure si els paquets UDP arriben, ni que sigui, al servidor separa en un minut els problemes de xarxa dels de configuració.
• Ignorar la MTU. El símptoma —connecta i després es penja amb transferències grans— sembla qualsevol cosa menys fragmentació.
• Consell de mètode. Abans de tancar un port, verifica des del client que ja hi arribes per la VPN. La regla del curs no admet excepcions: no tanquis mai la porta per la qual estàs entrant.

La Marta et truca des d'un hotel: «la VPN diu que està connectada però no puc entrar al tauler». Diagnostica el problema de manera sistemàtica, del més probable al menys, i resol-lo.

Dissenya el procediment complet de resposta davant la pèrdua del mòbil de la Marta amb la VPN configurada, en forma de manual d'operació, i inclou-hi el que cal fer després perquè l'incident no es repeteixi igual.

La Marta pregunta si amb la VPN «ja estem segurs» i si es poden simplificar altres mesures ara que la xarxa està protegida. Redacta la resposta.

Solució 1

Mètode: de fora cap a dins, i del més probable al menys. Cada pas descarta una capa sencera, i aquell ordre estalvia la major part del temps.

Hi ha salutació recent: el túnel està criptogràficament establert, la clau és correcta, el port UDP hi arriba i el Wi-Fi de l'hotel deixa passar. Això descarta d'un cop les quatre causes més freqüents.

Però fixa't en 0 B sent: el servidor rep de la Marta i no li envia res. Aquell detall apunta directament a encaminament o filtratge, no a la VPN.

Tres SYN sense resposta. El paquet de la Marta travessa el túnel correctament i arriba al servidor. El problema és després de la VPN: alguna cosa entre el servidor i el port 8404 no respon. La VPN queda descartada per complet.

Aquí està. IN=wg0 OUT=enp0s3 significa que el paquet està sent reenviat, no lliurat localment: el tauler d'HAProxy viu a 10.0.2.20, que és una altra màquina. I ufw denega el reenviament per defecte — la regla allow ... to any port 8404 s'aplica a la cadena d'entrada, no a la de reenviament.

Confirmat. El pas 11 de la lliçó es va aplicar a mitges: es va permetre el trànsit cap al servidor però no el reenviament a través seu.

Resolució:

L'opció B és la correcta i mereix defensar-se: manté la política de llista blanca de 06-03, on el reenviament per defecte continua denegat i només es permet explícitament el que cal. L'opció A obre el reenviament de qualsevol cosa a qualsevol lloc a través del servidor VPN, que és precisament el tipus de permís ampli que el model d'amenaces de 06-06 desaconsella.

Verificació:

L'arbre de decisió resumit, que va al manual d'operació per a la propera vegada:

I les tres lliçons d'aquest incident:

1. wg show respon en un segon la pregunta més important: si hi ha salutació, el problema no és la VPN. És la primera ordre, sempre.
2. L'asimetria received / sent és un indicador molt potent que gairebé ningú no mira: diu si la fallada és al camí d'anada o al de tornada.
3. Un tallafocs amb el reenviament denegat és la causa número u de «la VPN connecta però no arribo enlloc», i no apareix a ufw status de manera evident. Els missatges UFW BLOCK del nucli el delaten en deu segons.

Solució 2

Manual d'operació: Pèrdua o robatori d'un dispositiu amb VPN

Document: RB-SEG-04 · Versió: 1.0 · Data: 2026-08-18 Severitat: Alta · Temps objectiu de contenció: 15 minuts des de l'avís Ubicació: arxivador d'operacions i ~/tramontana-infra/docs/. Còpia impresa: la resposta pot haver-se de donar des d'un mòbil, sense accés al servidor.

0. Avaluació inicial (2 min)

Tres preguntes, i no s'espera a tenir les respostes per començar el pas 1:

Pregunta	Per què importa
El dispositiu té bloqueig de pantalla i xifratge?	Determina si la clau és accessible
Hi tenia desades altres credencials (correu, pass, SSH)?	Amplia l'abast molt més enllà de la VPN
Perdut o robat?	Un robatori dirigit implica un adversari amb intenció

S'assumeix el pitjor cas fins a demostrar el contrari. Retirar l'accés d'un dispositiu que després apareix costa cinc minuts de reconfiguració; no retirar-lo pot costar la base de dades.

1. Contenció immediata (5 min) — fer això ABANS d'investigar

# 1.1 Identificar la clau publica del dispositiu
$ grep -B3 '10.8.0.4/32' /etc/wireguard/wg0.conf
# --- marta-mobil (alta: 2026-08-18) ---
[Peer]
PublicKey = eF7gH8iJ9kL0mN1oP2qR3sT4uV5wX6yZ7aB8cD9eF0g=

# 1.2 RETIRAR EL PARELL EN CALENT. Efecte immediat, sense tallar ningu mes.
$ sudo wg set wg0 peer 'eF7gH8iJ9kL0mN1oP2qR3sT4uV5wX6yZ7aB8cD9eF0g=' remove

# 1.3 Confirmar que ha desaparegut
$ sudo wg show wg0 peers | grep -c 'eF7gH8iJ9k'
0

# 1.4 Bloquejar tambe la IP, per si de cas (defensa en profunditat)
$ sudo ufw insert 1 deny from 10.8.0.4 comment 'INCIDENT 2026-08-18'

A partir d'1.2, aquell dispositiu és indistingible d'un desconegut d'Internet. No hi ha llista de revocació que propagar ni finestra de caducitat: WireGuard descarta sense respondre els paquets de claus que no coneix.

2. Persistència del canvi (3 min)

# Sense aixo, el parell torna en reiniciar la interficie o el servidor
$ sudo cp /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak-$(date +%F)
$ sudo sed -i '/--- marta-mobil/,/^$/d' /etc/wireguard/wg0.conf
$ sudo diff -u /etc/wireguard/wg0.conf.bak-$(date +%F) /etc/wireguard/wg0.conf
$ sudo shred -u /etc/wireguard/clients/marta-mobil.conf

I al repositori d'Ansible, perquè si no es treu d'allà, el següent ansible-playbook el torna a donar d'alta:

$ cd ~/tramontana-infra
$ vim roles/vpn/defaults/main.yml     # eliminar l entrada marta-mobil
$ ansible-vault edit group_vars/all/vault.yml   # eliminar les seves claus
$ git commit -am "Baixa de marta-mobil: dispositiu perdut 2026-08-18"
$ ansible-playbook lloc.yml --limit srv-tramontana --tags vpn --check --diff

3. Avaluació d'abast (15 min)

# 3.1 Hi va haver activitat des del moment de la perdua?
$ sudo journalctl -t wireguard --since "2026-08-18 09:00" | tail -20

# 3.2 Accessos a la base de dades des de la seva IP de VPN
$ sudo journalctl -u postgresql@16-main --since "2026-08-18 09:00" | \\
      grep '10.8.0.4'

# 3.3 Accessos al tauler d estadistiques
$ journalctl -t nginx_acces --since "2026-08-18 09:00" | grep '10.8.0.4'

# 3.4 Sessions SSH
$ sudo last -i | grep '10.8.0.4'
$ sudo journalctl -u ssh --since "2026-08-18 09:00" | grep 'Accepted'

Troballa	Conclusió	Acció addicional
Sense activitat després de la pèrdua	Contenció a temps	Cap
Activitat compatible amb l'ús normal de la Marta	Probablement ella	Confirmar-ho amb ella
Activitat anòmala (hores estranyes, consultes massives)	Compromís probable	Escalar al pas 6

4. Altres credencials del dispositiu (20 min)

La VPN gairebé mai no és l'única cosa que hi ha en un mòbil. Es revisa i es rota tot el que hi hagués:

Credencial	Acció	Responsable
Correu corporatiu	Tancar sessions remotes i canviar la contrasenya	Marta
Clau SSH (si en tenia)	Treure-la d'authorized_keys a tots els amfitrions	Operacions
Contrasenya de PostgreSQL	Rotar-la a pass i amb ALTER ROLE	Operacions
Sessions de Tramontana Reserves	Invalidar totes les d'aquell compte	Luis
Gestor de contrasenyes	Canviar la clau mestra	Marta
Segon factor (TOTP)	Regenerar i revisar els codis de recuperació	Marta

# Exemple: rotar la contrasenya de la base de dades
$ pass generate -f tramontana/db 32
$ sudo -u postgres psql -c "ALTER ROLE operador PASSWORD '$(pass tramontana/db)';"

5. Restabliment del servei (10 min)

# Quan la Marta tingui dispositiu nou: parell NOU, IP NOVA.
# No es reutilitza ni la clau ni l adreca: reutilitzar la IP
# confondria els registres de l incident amb l activitat legitima
# posterior.
$ sudo ~/scripts/alta_vpn.sh marta-mobil2
[..] donant d alta 'marta-mobil2' amb IP 10.8.0.7

El QR s'escaneja presencialment o en videotrucada amb la Marta ensenyant la pantalla del mòbil nou. Mai per missatgeria.

6. Escalat

Es declara incident de seguretat complet —i se segueix el procediment de 06-04— si es compleix qualsevol d'aquestes condicions:

• Hi ha activitat des de la IP del dispositiu posterior al moment de la pèrdua.
• El dispositiu no tenia bloqueig de pantalla ni xifratge.
• Contenia claus SSH o credencials d'administració.
• Va ser un robatori dirigit, no un extraviament.

7. Prevenció: què es canvia per a la propera vegada

Aquesta és la part que converteix un incident en una millora, i la que gairebé tots els procediments ometen.

Mesura	Estat	Justificació
Xifratge i bloqueig obligatoris a tot dispositiu amb VPN	Pendent: política per escriure	Sense xifratge, la clau privada és llegible extraient-ne la memòria
Registrar qui té quin dispositiu i amb quin accés	Pendent: inventari	Avui cal buscar-ho a wg0.conf per saber-ho
Mínim privilegi per parell: el mòbil no necessita PostgreSQL	Aplicar ja	Redueix l'abast de la propera pèrdua
Alerta automàtica si un parell nou o inactiu connecta	Pendent (08-06)	Detecció, no només prevenció
Revisió trimestral de parells i baixes	Aplicar ja	Els parells s'acumulen i ningú no els treu
Assaig anual d'aquest manual d'operació	Aplicar ja	Un procediment no assajat és una suposició

# Minim privilegi per a dispositius mobils, aplicat avui mateix
$ sudo ufw deny from 10.8.0.7 to any port 5432 proto tcp \\
      comment 'mobil: sense acces a la BD'
$ sudo ufw deny from 10.8.0.7 to any port 22 proto tcp \\
      comment 'mobil: sense SSH'

8. Registre

S'anota al quadern de guàrdia (08-06): data i hora de l'avís, hora de la contenció, abast avaluat, credencials rotades i mesures preventives acordades. Sense culpables: perdre un mòbil no és una falta, i tractar-ho com a tal garanteix que la propera vegada triguin dos dies a avisar — que és l'única cosa que convertiria aquest incident en un desastre.

Solució 3

Sobre la VPN: què hi hem guanyat i què no canvia Per a: Marta Vidal · De: Operacions de sistemes · 18 d'agost de 2026

Resposta breu: hi hem guanyat força, i no, no podem simplificar res. De fet, la VPN funciona precisament perquè la resta de mesures continuen al seu lloc.

---

Què hem muntat. Un túnel xifrat que permet al teu portàtil i al teu mòbil comportar-se, des de qualsevol lloc del món, com si estiguessin endollats a la xarxa de l'oficina. Necessites una clau digital única del teu dispositiu; sense ella, el servidor ni tan sols respon: per a qualsevol que l'escanegi des d'Internet, aquell punt d'entrada és indistingible d'un que no existeix.

Què hi hem guanyat, en concret:

Abans	Ara
Per veure els informes des de casa calia demanar-m'ho	Hi entres directament amb les teves eines
La base de dades era inabastable des de fora	Abastable només pel túnel
El tauler d'estat, igual	Igual
Al Wi-Fi d'un hotel, el trànsit intern aniria en clar	Va xifrat d'extrem a extrem
Qualsevol servei nou que volguessis fer servir des de fora calia publicar-lo	Ja és accessible, sense publicar res

L'important: hem tancat portes, no obert. Abans, perquè poguessis treballar des de fora, l'única opció hauria estat publicar la base de dades a Internet. Amb la VPN hem fet el contrari: hi ha menys coses exposades que ahir, i tot i així pots arribar a més.

Ara la pregunta que em fas, i la resposta és que no. Entenc per què la fas: si la xarxa està protegida, sembla raonable relaxar el de dins. És un raonament molt estès i és la causa d'una part important de les bretxes de seguretat que surten a les notícies.

El motiu, amb un exemple concret. Imagina't que el teu portàtil s'infecta amb un programa maliciós —per un correu, per un web, per una memòria USB—. Aquell programa és dins del teu portàtil, i el teu portàtil és dins del túnel. Per a ell, la VPN no és cap obstacle: és una autopista directa a la base de dades de reserves. La VPN comprova que el dispositiu és teu; no comprova què està fent el dispositiu.

Per això tota la resta continua sent necessari:

Mesura	Es pot relaxar?	Per què
Contrasenya de la base de dades	No	És l'única cosa que atura un programa maliciós ja dins del túnel
Xifratge de les connexions internes	No	El túnel acaba al servidor; d'allà endavant no protegeix
Bloqueig d'intents d'accés repetits	No	Algú pot arribar per altres vies
Còpies de seguretat	No	La VPN no protegeix d'errors ni d'esborrats
Actualitzacions de seguretat	No	Una fallada en un programa s'explota igual des de dins
Registre de qui accedeix a què	No, al contrari	Ara hi ha més maneres d'arribar-hi: cal vigilar més

La manera correcta de veure-ho, i és com es treballa avui al sector: no existeix «dins segur» i «fora perillós». Cada servei comprova qui ets i xifra el seu, sigui qui sigui a l'altre costat. La VPN és una capa més, no un mur que permeti abaixar la guàrdia al darrere.

El que sí que hem pogut fer gràcies a la VPN, i això sí que és una simplificació real: restringir per persona. Com que cada dispositiu té una adreça fixa garantida pel mateix sistema —no es pot falsificar—, he pogut deixar que tu arribis a la base de dades i que el Luis, que és desenvolupador i no la necessita en producció, no hi pugui. Abans això no era possible de manera fiable. És menys accés, més ben repartit.

Dues coses que necessito de la teva part:

1. Que el mòbil i el portàtil tinguin bloqueig de pantalla i xifratge activats. La clau digital viu al dispositiu; si algú l'encén i hi entra sense contrasenya, té la clau. És l'única mesura que depèn de tu i és la més important de totes.
2. Que m'avisis immediatament si perds un dispositiu, a qualsevol hora. Retirar-li l'accés em porta dos minuts i és instantani: no hi ha finestres ni esperes. Perdre un mòbil no és un problema; trigar un dia a dir-ho, sí. Tinc el procediment escrit i assajat.

I una cosa més, per al registre. He aprofitat per tancar a l'exterior la base de dades i el tauler d'estat, que fins ara depenien d'estar físicament a la xarxa de l'oficina. He deixat obert l'accés d'administració habitual, i no per descuit: si la VPN fallés després d'una actualització, sense aquella segona via hauria de desplaçar-me físicament al servidor per arreglar-la. El tancaré quan tinguem una alternativa provada, no abans. És la regla que aplico sempre: no es tanca mai la porta per la qual estàs entrant.

La VPN està muntada i ha pagat el seu cost immediatament: PostgreSQL i el tauler d'estadístiques estan tancats a l'exterior i, alhora, són accessibles des de qualsevol lloc. El servidor exposa un port UDP més que ahir, i aquell port no respon a qui no té clau, cosa que el fa indistingible d'un de tancat per a qualsevol escàner d'Internet. És l'intercanvi que buscaves: menys superfície exposada i més abast.

Entens WireGuard per dins, que era l'objectiu real. Saps que és una interfície de xarxa i no un dimoni, i que per això les eines de 06-01 i les regles de 06-03 s'hi apliquen tal qual. Saps que no hi ha servidor ni client al protocol, només parells amb claus públiques. I sobretot entens AllowedIPs, que és el concepte que separa qui ha copiat una configuració de qui sap què fa: en enviar és una taula de rutes, en rebre és un filtre antisuplantació, i per això al servidor cada client porta el seu /32 i 0.0.0.0/0 només apareix al costat del client. Aquell doble paper és el que fa que la IP de VPN de cada persona sigui un identificador fiable, i el que t'ha permès donar accés a la base de dades a uns dispositius i negar-lo a d'altres.

Has decidit el túnel dividit amb arguments —amplada de banda, privadesa de les persones i l'objectiu real, que és arribar al que és intern— en lloc de per costum. Has verificat el xifratge capturant els mateixos paquets a les dues interfícies: opacs a enp0s3, llegibles a wg0. Has automatitzat l'alta de clients amb wg syncconf, que aplica canvis sense tallar ningú, i amb un creates: a Ansible que impedeix el desastre de regenerar la clau del servidor. I no has tancat SSH, perquè una segona via d'accés provada va abans que l'elegància.

I t'endus la frase que més importa de tota la lliçó: una VPN no converteix una xarxa interna en una xarxa segura. Trasllada el punt de confiança, redueix l'exposició i dona un identificador fiable per dispositiu. No protegeix d'un portàtil infectat, ni d'una contrasenya feble, ni del moviment lateral un cop a dins. Tot el que vas muntar al Mòdul 6 continua sent igual de necessari avui que ahir.

A 08-05 arriba el projecte més gran del mòdul i el que exigeix més honestedat: un clúster de Kubernetes. La lliçó et dirà des del primer paràgraf que per a Tramontana és desproporcionat, i t'explicarà exactament per què, amb números. I tot i així la faràs sencera, perquè és la tecnologia dominant del sector i perquè te la trobaràs a la teva feina. Muntaràs k3s sobre srv-tramontana-proves, entendràs el pla de control peça a peça, desplegaràs Tramontana Reserves amb Deployments, Services, Ingress, ConfigMaps i Secrets —i veuràs que un Secret és base64, no xifrat, cosa que enllaça directament amb 06-05—, i aprendràs a llegir un CrashLoopBackOff en lloc de témer-lo. Amb el tancament honest sobre la complexitat operativa real de mantenir un clúster viu.