Les dues lliçons anteriors van deixar una paradoxa oberta: el PC de la Marta té l'adreça privada 192.168.10.21, els routers d'Internet descarten qualsevol paquet amb adreces RFC 1918… i tot i això la Marta navega sense problemes. El truc es diu NAT (Network Address Translation, traducció d'adreces de xarxa) i viu al router de València: reescriu les adreces dels paquets en sortir i en tornar. En aquesta lliçó veuràs pas a pas com ho fa, què és aquesta taula de traduccions IP:port que ho fa possible, com es publica un servei intern amb port forwarding, i — molt important per a la teva carrera — quines coses trenca NAT i per què. NAT és una de les tecnologies més presents i invisibles de les xarxes actuals: entendre-la t'explicarà dotzenes de comportaments "estranys" que veuràs a suport, cloud i desenvolupament.

1. El problema: esgotament d'IPv4 i adreces no encaminables
2. NAT d'origen (SNAT/masquerade): el viatge d'una petició de la Marta
3. PAT / NAT overload: el cas real de gairebé totes les xarxes
4. Tipus de NAT: estàtic, dinàmic i PAT
5. Port forwarding (DNAT): publicar la intranet cap enfora
6. El que NAT trenca: el preu del pedaç
7. NAT com a "pseudotallafoc"
8. Curiositats operatives: hairpin NAT i doble NAT

Recapitulem les peces de les lliçons anteriors:

• IPv4 té ~4.300 milions d'adreces; semblaven infinites i no ho eren. IANA va esgotar els seus blocs lliures el 2011 i els RIR després.
• La resposta dels anys 90 va ser doble: CIDR (assignar amb precisió, sense classes) i RFC 1918 (rangs privats reutilitzables per tothom).
• Però les privades tenen la limitació que ja coneixes: no són encaminables a Internet. No és una limitació tècnica del format del paquet — un datagrama IP amb origen 192.168.10.21 és perfectament vàlid —, sinó una regla de filtratge: com que milions de xarxes fan servir els mateixos rangs, una adreça privada no identifica ningú de manera única, i els routers de les operadores descarten aquests paquets. A més, encara que la teva petició sortís, la resposta no sabria tornar: a quin dels milions de 192.168.10.21 del planeta?

Meridiano té 20 equips a València i el seu ISP li dona una IP pública (farem servir la fictícia de documentació 203.0.113.50). Els comptes no surten: 20 equips, 1 adreça vàlida a Internet. NAT és el mecanisme que fa que surtin: tots els equips interns comparteixen la IP pública del router, que actua d'intermediari reescrivint paquets.

SNAT (Source NAT) significa reescriure l'adreça d'origen dels paquets que surten. Quan la IP pública és la de la mateixa interfície del router i pot canviar (típic amb ISP domèstics i de pime), la variant s'anomena masquerade ("emmascarament"): els equips interns surten "disfressats" del router.

Seguim un cas complet: la Marta obre al navegador el web d'un proveïdor públic, www.proveedor-cloud.example, que resol (DNS, mòdul 2) a 198.51.100.80. El seu navegador obre una connexió TCP al port 443 des d'un port efímer local, posem el 51612 (ports i sockets: mòdul 2).

Pas 1 — El paquet surt del PC de la Marta:

Destinació fora de la seva xarxa (AND amb la màscara, lliçó 05-02) → el paquet va al gateway 192.168.10.1.

Pas 2 — El router tradueix i pren nota. Abans de reenviar el paquet cap a Internet, el router:

1. Substitueix la IP d'origen privada per la seva IP pública: 192.168.10.21 → 203.0.113.50.
2. Substitueix (si cal, i a la pràctica sempre) el port d'origen per un de lliure propi: 51612 → 40001.
3. Apunta la traducció a la seva taula de NAT, la peça clau de tot el mecanisme:

El paquet viatja per Internet amb aquest aspecte — el servidor no veu mai la 192.168.10.21:

Pas 3 — La resposta torna i es desfà la traducció. El servidor respon a l'única cosa que coneix: 203.0.113.50:40001. El router rep la resposta, busca 40001 a la seva taula, troba la fila de la Marta i reescriu la destinació: 203.0.113.50:40001 → 192.168.10.21:51612. Lliura el paquet a la LAN i el navegador de la Marta rep la seva resposta com si no hagués passat res.

Detalls operatius que convé saber:

• Les entrades de la taula caduquen: si una connexió deixa de tenir trànsit (TCP tancat o inactiu, UDP al cap d'uns segons/minuts), el router esborra la fila i reutilitza el port. Per això les connexions llarguíssimes i inactives "cauen a través de NAT" i els protocols fan servir keepalives.
• NAT recalcula les sumes de verificació (checksum) d'IP i TCP/UDP a cada reescriptura: la capçalera canvia, la signatura ha de canviar.
• El servidor de logs del proveïdor registrarà que "203.0.113.50 va fer la petició": des de fora, tota Meridiano-València és una sola adreça.

El que acabem de descriure — moltes IP privades compartint una IP pública, distingides per port — té nom propi: PAT (Port Address Translation), també anomenat NAT overload o NAPT. És el que fa el teu router de casa i el de Meridiano.

La clau és a la columna de ports. Si alhora que la Marta navega, l'Ana consulta el mateix web, la taula distingeix les dues connexions sense ambigüitat:

Amb ~64.000 ports utilitzables per IP pública, una sola adreça suporta desenes de milers de connexions simultànies — de sobres per als 20 equips de València, i la raó que IPv4 continuï viu dues dècades després d'"esgotar-se". Quan el mecanisme l'aplica l'operadora per compartir una IP pública entre diversos clients s'anomena CGNAT (Carrier-Grade NAT); te'l trobaràs en connexions mòbils i de fibra barates, i agreuja tots els problemes de l'apartat 6.

Quan algú diu "NAT" a seques el 2026, gairebé sempre vol dir PAT. A Meridiano: PAT al router de València (tots surten com a 203.0.113.50) i PAT al de Bilbao amb la seva pròpia IP pública. Nota important: el trànsit entre seus per la VPN lloc a lloc no es tradueix amb NAT — dins del túnel, la Marta (192.168.10.21) i en Jon (192.168.20.7) es veuen amb les seves adreces privades reals; per a això hi ha la VPN.

SNAT resol les connexions sortints. I les entrants? Suposa que en Jon és de viatge, sense VPN, i vol consultar la intranet (https://grupomeridiano.example, que serveix el 192.168.10.10 pel port 443, amb la seva API GET /api/proyectos). Algú de fora que connecti a 203.0.113.50:443 topa amb el problema simètric: el router rep el paquet, busca a la seva taula NAT… i no hi ha cap fila, perquè ningú de dins no va iniciar aquesta connexió. Sense més informació, el router el descarta.

La solució és DNAT (Destination NAT) o port forwarding: una regla estàtica que l'administrador escriu a mà al router:

Amb aquesta regla, la petició externa d'en Jon viatja així:

El port extern no ha de coincidir necessàriament amb l'intern: es podria publicar 203.0.113.50:8443 → 192.168.10.10:443.

I per què Meridiano NO ho fa? Perquè publicar un port és obrir una porta a tot Internet, no només a en Jon: bots d'escaneig trobarien el servei en hores i provarien credencials i vulnerabilitats contra la intranet — un servidor intern que mai no es va dissenyar per estar exposat. La política de Meridiano és la recomanada per a aquest cas: els serveis interns s'arriben a tocar a través de la VPN (l'empleat remot es connecta a la VPN i accedeix al 192.168.10.10 com si fos a l'oficina), i només es publica amb DNAT allò que està pensat, mantingut i vigilat per ser públic. El port forwarding no és dolent en si — és com es publica qualsevol servei autoallotjat —; el que és perillós és fer-lo servir com a drecera per exposar serveis interns.

Al mòdul 4 vam veure la filosofia extrem a extrem de TCP/IP: la xarxa només transporta; la intel·ligència és als extrems, i qualsevol host pot parlar amb qualsevol host. NAT trenca aquesta simetria: darrere de NAT ja no ets un extrem ple d'Internet — pots iniciar connexions, però no rebre'n. Conseqüències concretes:

• Servidors a casa / a la LAN: invisibles des de fora sense DNAT explícit. "Munto un servidor al meu PC i passo la meva IP a un amic" no funciona: la teva 192.168.x.x no li serveix, i la teva IP pública arriba al router, que descarta la connexió entrant.
• P2P, videotrucades i jocs en línia: dos usuaris, tots dos darrere de NAT, no es poden connectar directament — cap dels dos no pot rebre. La indústria va construir una capa sencera de marrades (STUN, TURN, ICE, hole punching, servidors intermediaris) només per travessar NAT. Si alguna vegada una videotrucada t'ha anat per "relay" amb lag, has pagat l'impost NAT.
• Pèrdua de visibilitat extrem a extrem: el servidor veu 203.0.113.50 facin el que facin els 20 equips de València. Per al proveïdor, un abús d'un equip infectat i el trànsit legítim de la Marta són la mateixa adreça: bans i captchas col·lectius. Amb CGNAT, comparteixes reputació amb desconeguts.
• Protocols que duen IP dins de les dades: NAT reescriu capçaleres, no el cos. L'FTP actiu del mòdul 2 és l'exemple clàssic: el client envia dins del canal de dades la IP a què el servidor s'ha de connectar — i envia la privada, que no serveix. Els routers ho apedacen amb "ALG" (inspectors per protocol), una altra peça de complexitat que de vegades causa més fallades de les que arregla.
• Fragilitat de connexions llargues: si l'entrada de la taula NAT caduca per inactivitat, la connexió mor silenciosament (típic en SSH o websockets inactius).

Guarda aquesta idea: NAT no és un principi de disseny, és un pedaç brillant a l'esgotament d'IPv4. Funciona tan bé que es va tornar permanent, però el seu cost en complexitat és una de les motivacions centrals d'IPv6 (pròxima lliçó).

Hauràs sentit "estàs protegit, tens NAT". Té una base real: com que les connexions entrants sense entrada a la taula es descarten, NAT bloqueja de facto l'accés directe des d'Internet als equips interns. És un efecte secundari valuós… però no és un tallafoc:

• No inspecciona ni filtra el trànsit sortint: un equip infectat a la VLAN corporativa parla amb el seu servidor de control sense que NAT digui res.
• No protegeix de res que iniciï la víctima: phishing, descàrregues malicioses, webs compromesos.
• No filtra dins de la LAN: entre el PC de la Marta i el de l'Ana no hi ha cap NAT.
• Les seves "excepcions" s'obren amb facilitat (UPnP permet a les aplicacions — i al malware — crear regles DNAT automàticament en molts routers domèstics).

La postura correcta: NAT més un tallafoc amb regles explícites (els routers de pime integren tots dos). A Meridiano, el router de València fa PAT i aplica regles: la VLAN 20 de convidats surt a Internet però no arriba a la VLAN corporativa ni als servidors.

Dues situacions que veuràs a la pràctica i que convé saber anomenar, sense aprofundir-hi:

• Hairpin NAT (NAT loopback): la Marta, des de dins, obre la URL pública 203.0.113.50:443 (o un DNS públic que hi apunta) en lloc de la interna. El paquet va al router i ha de "girar cua en forquilla": aplicar DNAT cap al 192.168.10.10 i SNAT perquè la resposta torni pel router. No tots els routers ho suporten bé — d'aquí el clàssic "el web funciona des del mòbil amb 4G però no des de l'oficina". La solució elegant és el split DNS: que grupomeridiano.example resolgui a la IP interna dins de la LAN i a la pública a fora.
• Doble NAT (NAT 444): dues traduccions encadenades — per exemple, el router de l'ISP fa NAT i darrere el router propi de l'empresa en fa un altre; o CGNAT de l'operador + NAT del client. Tot el sortint funciona; el port forwarding es complica (caldria obrir el port als dos nivells, i al CGNAT no pots) i els problemes de l'apartat 6 es dupliquen. Diagnòstic ràpid: si la IP WAN que mostra el teu router és privada o del rang 100.64.0.0/10 (reservat per a CGNAT), hi ha un altre NAT per sobre.

• Donar la IP privada a algú de fora. "Connecta't a la meva 192.168.10.21" només té sentit dins de la mateixa xarxa (o via VPN). Per saber com et veu Internet, consulta un servei de "quina és la meva IP": veuràs la pública del router.
• Confondre NAT amb la VPN. El trànsit entre València i Bilbao pel túnel VPN conserva les IP privades d'origen a destinació; NAT només actua en el trànsit cap a Internet.
• Obrir port forwarding "per provar" i oblidar-lo. Cada regla DNAT és una exposició permanent; documenta, limita i revisa les regles del router.
• Creure que NAT substitueix el tallafoc. Bloqueja entrants no sol·licitades i res més; el trànsit sortint i el lateral necessiten regles explícites.
• Sorprendre's que "tots sortim amb la mateixa IP". És el comportament normal de PAT; si un servei extern us bandeja a tots per l'abús d'un equip, aquest és el perquè.
• Consell: quan una app "funciona en una direcció però no en l'altra" (trucada que només se sent en un sentit, servidor abastable només des de fora), pensa en NAT: qui va iniciar la connexió?, hi ha fila a la taula per a l'altre sentit?
• Consell: en diagnòstics, distingeix sempre tres adreces: la privada de l'equip, la pública del router i la de la destinació. Escriure-les evita el 90 % de les confusions amb NAT.

Des de València, simultàniament: la Marta (192.168.10.21) obre una connexió TCP al port 443 de 198.51.100.80 des del seu port 51700, i l'Ana (192.168.10.22) n'obre una altra al mateix servidor i port des del seu port 51700 (casualitat perfectament possible). La IP pública del router és 203.0.113.50. a) Escriu la taula NAT resultant (tria ports externs plausibles). b) Arriba del servidor un paquet amb destinació 203.0.113.50:40002. A qui el lliura el router i amb quina destinació reescrita? c) Per què el router no pot conservar el port 51700 per a totes dues?

Meridiano vol que un client extern consumeixi GET /api/proyectos de la intranet (192.168.10.10:443) durant un projecte de 2 setmanes. Un tècnic proposa la regla DNAT 203.0.113.50:8443 → 192.168.10.10:443. a) Escriu com quedarien origen i destinació del paquet de petició del client (IP pública del client: 198.51.100.7, port efímer 50123) abans i després del router. b) Dona dos riscos d'aquesta solució i una alternativa més segura coherent amb la política de Meridiano.

Un empleat es queixa: "des de casa no puc fer ping al meu PC de l'oficina (192.168.10.30), però des del PC de l'oficina sí que navego per Internet". Explica els dos comportaments fent servir la taula NAT, i indica la manera correcta d'accedir al PC de l'oficina des de casa.

Solució 1

a) El router assigna a cada connexió un port extern lliure diferent:

b) El router busca el port extern 40002 a la taula → fila de l'Ana. Reescriu la destinació a 192.168.10.22:51700 i el lliura a la LAN a l'Ana.

c) Si totes dues sortissin com a 203.0.113.50:51700 cap al mateix servidor i port, les dues connexions serien indistingibles a la tornada: la tupla (IP externa, port extern, IP remota, port remot, protocol) ha de ser única. El port extern és precisament el discriminador que permet a una sola IP pública multiplexar moltes connexions internes — l'essència de PAT.

Solució 2

a)

b) Riscos (dos d'entre aquests): (1) el port queda exposat a tot Internet, no només al client: els escàners el trobaran i provaran atacs contra un servidor intern no endurit; (2) la intranet sencera (no només /api/proyectos) queda abastable per aquest port; (3) el clàssic "regla temporal" que ningú no retira al cap de 2 setmanes. Alternativa coherent amb Meridiano: donar al client accés VPN limitat (o publicar l'API en un servidor específic i aïllat, mantingut per a exposició pública, restringint per tallafoc les IP d'origen del client) — mai DNAT directe al servidor intern.

Solució 3

• Navegar des de l'oficina funciona: el PC 192.168.10.30 inicia la connexió; el router crea l'entrada SNAT a la seva taula i les respostes troben la seva fila de tornada.
• El ping des de casa falla: el paquet arriba a la IP pública 203.0.113.50 com a trànsit entrant no sol·licitat; no existeix cap entrada a la taula NAT que digui a quina IP privada correspon (i cap regla DNAT no ho defineix), així que el router el descarta. A més, la 192.168.10.30 és privada: des de casa ni tan sols és una adreça abastable.
• Manera correcta: connectar-se a la VPN de Meridiano des de casa; dins del túnel, l'empleat arriba al 192.168.10.30 amb la seva adreça privada real, sense exposar res a Internet.

Ja tens el quadre complet del món IPv4 real: adreces privades RFC 1918 a dins, una IP pública compartida a fora, i al mig el router fent PAT amb la seva taula de traduccions IP:port — creant files quan algú de dins inicia una connexió, desfent-les a la tornada i descartant l'entrant no sol·licitat llevat que un port forwarding (DNAT) digui el contrari. Saps per què Meridiano prefereix la VPN a publicar la seva intranet, què trenca NAT (servidors casolans, P2P, la visibilitat extrem a extrem del mòdul 4) i per què el seu efecte "pseudotallafoc" no substitueix un tallafoc de veritat.

Però no perdis de vista la naturalesa de tot això: NAT és un pedaç — genial, omnipresent, però pedaç — sobre un espai d'adreces que es va quedar petit. La solució de fons existeix des dels anys 90 i fa dècades que es desplega: un protocol amb tantes adreces que cada dispositiu del planeta pot tornar a ser un extrem ple de la xarxa, sense traduccions. És la pròxima lliçó, l'última del mòdul: Introducció a IPv6.