Pugem un esglaó en la pila: a sota queden les interfícies i els seus enllaços (04-02); ara entrem a la capa que dona nom a tot l'invent — la capa d'Internet, la feina de la qual és que un paquet creui d'una xarxa a una altra fins a arribar a la seva destinació, sigui on sigui. Els seus protagonistes ja són vells coneguts: IP (02-03) i ICMP, juntament amb la funció d'encaminament (03-04). El que aporta aquesta lliçó és la part que encara no has tocat: la capa vista des de dins d'un sistema real — llegir taules de rutes línia a línia amb ip route i route print, entendre la ruta per defecte i les mètriques, i veure què passa a la pràctica quan un paquet xoca amb la MTU del túnel VPN de Meridiano. És important perquè la taula de rutes és la primera parada de gairebé qualsevol diagnòstic de connectivitat: si la ruta està malament, tota la resta tant se val.

1. Què viu a la capa d'Internet
2. L'encaminament com a funció de la capa
3. La taula de rutes a la pràctica: ip route a Linux
4. La mateixa taula a Windows: route print
5. Ruta per defecte i mètrica
6. Fragmentació i MTU a la pràctica: el cas de la VPN
7. El que deixem per al mòdul 5: l'adreçament a fons

La capa d'Internet de TCP/IP correspon a la capa de xarxa d'OSI, i el seu llogater central és el Protocol d'Internet (IP), que ja vas disseccionar a 02-03: paquets amb adreces lògiques d'origen i destinació, TTL, lliurament best effort sense connexió. No el repetirem; recordem-ne només el contracte: "dona'm un paquet i una adreça de destinació, i intentaré que arribi, xarxa a xarxa, sense garanties".

Però IP no viu sol en aquesta capa. L'acompanyen:

• ICMP (Internet Control Message Protocol): el missatger de servei d'IP (02-03). Com que IP no garanteix res, algú ha de poder avisar quan alguna cosa va malament: "destinació inabastable", "TTL esgotat", "fragmentació necessària". ICMP viatja dins de paquets IP, però conceptualment és part de la capa d'Internet, no un usuari seu: existeix perquè la mateixa capa funcioni i es pugui diagnosticar (ping i traceroute en viuen; els explotarem al mòdul 6).
• La funció d'encaminament (routing): decidir, paquet a paquet, per on continua el viatge. No és un protocol sinó un procés que executa tot dispositiu amb IP — no només els routers — fent servir la seva taula de rutes.
• Protocols auxiliars que només esmentem: els d'encaminament dinàmic (OSPF, BGP — presentats conceptualment a 03-04) que omplen taules de rutes automàticament, i IPv6 amb el seu propi ICMPv6, l'existència del qual ja coneixes i el detall del qual pertany al mòdul 5.

A 03-04 vas aprendre la idea: encaminament salt a salt, cada dispositiu decideix només el pas següent. Ara, la clau pràctica: aquesta decisió la pren el kernel consultant la seva taula de rutes per a cada paquet que envia. I això val tant per al router de València com per al PC de la Marta: quan la Marta obre la intranet, el seu propi PC executa l'algorisme:

1. Miro la IP de destinació del paquet.
2. Busco a la meva taula la ruta més específica que la contingui (longest prefix match: guanya el prefix més llarg).
3. Aquesta ruta em diu per quina interfície surt el paquet i, si la destinació no és a la meva pròpia xarxa, a quin salt següent (gateway) cal lliurar-lo.
4. Si cap ruta no encaixa ni hi ha ruta per defecte: error "xarxa inabastable" (i, en un router, un ICMP de tornada cap a l'origen).

Fixa't en el lligam amb la lliçó anterior: tota ruta acaba anomenant una interfície. La taula de rutes és el pont entre la capa d'Internet ("cap a on?") i la capa d'accés a la xarxa ("per quina porta?").

Vegem la taula real del servidor de la intranet (192.168.10.10, Linux):

Només dues línies — és un servidor, no un router — però cada paraula importa. Línia a línia:

Línia 2 (la llegim primer perquè és la més específica):

• 192.168.10.0/24 — la destinació: qualsevol IP de la xarxa local de València (el /24 que vas planificar a 02-03).
• dev enp3s0 — interfície de sortida: la targeta Ethernet del servidor (04-02).
• proto kernel — qui va crear la ruta: el mateix kernel, automàticament, en configurar-se la IP 192.168.10.10/24 a la interfície. Per això mai no "configures" aquesta ruta: neix amb l'adreça.
• scope link — la peça conceptual: la destinació és directament abastable a l'enllaç, sense gateway. Per arribar a la impressora o al PC de la Marta, el servidor no passa pel router: resol la MAC per ARP i lliura la trama directament (02-02).
• src 192.168.10.10 — quina IP d'origen cal fer servir als paquets que surtin per aquesta ruta (rellevant quan una màquina té diverses adreces).

Línia 1:

• default — sinònim de 0.0.0.0/0: qualsevol destinació no coberta per una altra ruta. És el prefix més curt possible, així que només guanya quan res més no encaixa.
• via 192.168.10.1 — el salt següent: el router de València. És, literalment, la "porta d'enllaç predeterminada" que vas veure a 02-03, ara en la seva forma nativa: una entrada més de la taula.
• proto static — la va posar una configuració explícita (o el client DHCP), no el kernel.

I una tercera eina preciosa per al diagnòstic — preguntar al kernel què decidiria, sense enviar res:

La presència o absència de via és la diferència entre "és de la meva xarxa" i "necessito el router" — la decisió fonamental que pren aquesta capa milions de vegades al dia.

En contrast, la taula del router de València té una línia més, i aquella línia és la VPN:

Aquesta tercera ruta és tot el secret de la comunicació entre seus: "per a la xarxa de Bilbao, surt per la interfície virtual del túnel". La resta la fa l'encapsulació xifrada que ja coneixes.

Al PC de la Marta (192.168.10.21, Windows), la informació és la mateixa amb un altre vestit:

Claus de traducció respecte de Linux:

Windows a més mostra rutes "de lampisteria" que Linux guarda a part: la loopback (127.0.0.0/8), l'adreça de difusió de la xarxa (192.168.10.255) i la difusió general (255.255.255.255). Són normals; no les toquis ni t'alarmis en veure-les.

Dos conceptes de la taula mereixen zoom propi.

La ruta per defecte (default / 0.0.0.0 0.0.0.0) és la xarxa de seguretat de la taula: "tot allò que no sàpiga on va, ho dono a aquest gateway, que en sabrà més que jo". És la que converteix una LAN aïllada en una xarxa connectada al món:

• Als PCs de Meridiano apunta al router de la seva seu (.10.1 o .20.1).
• Als routers de Meridiano apunta al router de l'operador.
• Als routers de l'operador apunta cap al nucli d'Internet... on els routers troncals ja no tenen ruta per defecte: tenen la taula completa d'Internet (apresa per BGP, com vam esmentar a 03-04). En algun punt, algú ho ha de saber tot.

Símptoma clàssic de la seva absència o error: "arribo als equips de la meva oficina però no a Internet ni a Bilbao". Xarxa local intacta (ruta scope link present), món exterior perdut — apunta directament a la ruta per defecte.

La mètrica resol empats: si dues rutes igual d'específiques porten a la mateixa destinació, guanya la de mètrica més baixa (menys cost). El cas quotidià és un portàtil amb cable i Wi-Fi connectats alhora: dues rutes per defecte, una per cada interfície. Windows assigna automàticament una mètrica menor al cable (més ràpid i estable), i per això el trànsit prefereix el cable encara que el Wi-Fi continuï actiu. Ordre complet de decisió de la capa:

1. Especificitat primer: guanya el prefix més llarg (una ruta /24 cap a 192.168.20.0 sempre guanya a default per al trànsit cap a Bilbao, sigui quina sigui la mètrica).
2. Mètrica després: només desempata entre rutes igual d'específiques.

A 04-02 vam deixar plantejat el límit: cada interfície declara la seva MTU. Ara, la reacció, que és competència d'aquesta capa. Recorda de 03-04 les dues opcions quan un paquet no cap a l'enllaç de sortida:

• Fragmentar-lo (partir-lo en trossos que la destinació final reassembla), si el paquet ho permet; o
• Descartar-lo i avisar amb un ICMP de "fragmentació necessària" si el paquet porta activada la marca DF (Don't Fragment), que és l'habitual avui: els emissors moderns prefereixen assabentar-se'n i ajustar (tècnica anomenada Path MTU Discovery) abans que pagar el cost i la fragilitat de la fragmentació.

El túnel de Meridiano és l'escenari perfecte per veure-ho fer mal. La MTU de tun0 és 1436, menor que els 1500 de les LAN. Imagina que el servidor .10 envia a en Jon paquets de 1500 bytes amb DF activat:

Aquest és el funcionament sa: l'ICMP arriba, l'emissor ajusta, ningú no se n'assabenta. La fallada clàssica apareix quan un tallafoc massa zelós bloqueja aquests missatges ICMP: el servidor no rep mai l'avís, continua enviant a 1500, i el símptoma és desconcertant — el ping funciona (paquets petits) i les transferències grans es pengen (paquets grans descartats en silenci). És el famós "forat negre de MTU", una de les avaries de VPN més comunes del món real.

Per no dependre només d'ICMP existeix un ajust preventiu que convé conèixer de nom: el MSS clamping. L'MSS (Maximum Segment Size) és la mida màxima de segment que TCP anuncia al seu interlocutor durant el handshake (02-04); el router del túnel pot reescriure aquest anunci a la baixa en passar els segments d'establiment, de manera que tots dos extrems acordin des del principi segments que, ja empaquetats en IP, càpiguen a la MTU del túnel. És un pedaç pragmàtic — la capa d'Internet retocant una negociació de transport — i precisament perquè és pragmàtic, omnipresent en routers VPN com els de Meridiano.

Hauràs notat que en tota la lliçó hem manejat prefixos (/24), màscares (255.255.255.0) i xarxes "privades" (192.168.x.x) amb la comprensió intuïtiva del mòdul 2. És suficient per llegir taules de rutes, però al darrere hi ha un món amb regles pròpies: com s'estructura exactament una adreça IPv4, com es calculen i divideixen subxarxes a mida (i si Meridiano obre una tercera seu i vol trossejar el seu espai d'adreces amb precisió?), per què aquestes adreces privades necessiten NAT per sortir a Internet, i com IPv6 replanteja el joc sencer. Tot això és exactament el mòdul 5, i no ho avancem: queda't amb la idea que l'adreçament és l'altra meitat d'aquesta capa, tan gran que mereix mòdul propi.

• Creure que només els routers tenen taula de rutes. Tot dispositiu amb IP la té i la consulta a cada enviament. Molts problemes "de xarxa" són en realitat una taula de rutes incorrecta al mateix equip.
• Oblidar el longest prefix match. La taula no es llegeix de dalt a baix: guanya la ruta més específica. Una ruta /24 errònia "segresta" trànsit encara que la ruta per defecte sigui correcta — clàssic després d'instal·lar un client VPN que injecta rutes.
• Confondre "En vínculo"/absència de via amb un error. Vol dir lliurament directe a la xarxa local, sense gateway. És el correcte per al teu propi /24.
• Diagnosticar "no hi ha Internet" sense mirar la ruta per defecte. "Veig la impressora però no la web" gairebé sempre és ruta per defecte absent/errònia o el seu gateway caigut. ip route / route print abans de reiniciar res.
• Bloquejar tot ICMP "per seguretat". ICMP no és només ping: transporta els avisos que necessita Path MTU Discovery. Filtrar-lo sencer crea forats negres de MTU — la fallada de "la VPN va, però els fitxers grans no".
• Consell: aprèn a fer servir ip route get <destinació>: pregunta al kernel la seva decisió exacta per a una destinació concreta, sense generar trànsit. És la manera més ràpida de verificar "per on sortiria aquest paquet?".

Amb la taula del router de València mostrada a la lliçó (tres rutes: default via operador dev wan0; 192.168.10.0/24 dev lan0; 192.168.20.0/24 dev tun0), indica interfície de sortida i salt següent (si n'hi ha) per a paquets destinats a: (a) 192.168.10.21 (PC de la Marta), (b) 192.168.20.5 (PC d'en Jon), (c) 93.184.216.34 (un servidor web d'Internet), (d) 192.168.30.7 (una xarxa que no existeix a Meridiano).

El portàtil de l'Ana mostra a route print dues rutes per defecte: una per Ethernet (gateway 192.168.10.1, mètrica 25) i una altra per Wi-Fi (gateway 192.168.10.1, mètrica 50). (a) Per quina interfície surt el seu trànsit cap a Internet i per què? (b) L'Ana desconnecta el cable: què passa amb la seva navegació? (c) Per què, per arribar al servidor .10, la mètrica d'aquestes dues rutes és irrellevant com a criteri primer?

Des de Bilbao, en Jon pot fer ping al servidor .10 i obrir pàgines lleugeres de la intranet, però la descàrrega d'un PDF de 8 MB es queda penjada sempre. L'administrador descobreix que el tallafoc perimetral de València descarta tot el trànsit ICMP entrant i sortint. Explica la cadena completa de la fallada (quins paquets moren, quin avís no arriba, per què el ping sí que funciona) i proposa dues solucions diferents.

Exercici 1: (a) Ruta 192.168.10.0/24 dev lan0: surt per lan0, sense salt següent (lliurament directe per ARP). (b) Ruta 192.168.20.0/24 dev tun0: surt pel túnel VPN cap al router de Bilbao. (c) Cap ruta específica no encaixa → default: surt per wan0 cap al router de l'operador. (d) També cau a default i surt per wan0: el router de València no sap que aquella xarxa "no existeix"; la lliurarà a l'operador i algun router del camí acabarà tornant un ICMP de destinació inabastable. Moralitat: la ruta per defecte atrapa tot el que és desconegut, existeixi o no.

Exercici 2: (a) Per Ethernet: totes dues rutes són igual d'específiques (0.0.0.0/0), així que desempata la mètrica i 25 < 50. (b) La ruta per Ethernet desapareix (la interfície perd la portadora, 04-02) i el trànsit passa a la ruta per defecte del Wi-Fi; la navegació continua, potser una mica més lenta — les connexions establertes es poden tallar en canviar el camí, però les noves flueixen. (c) Perquè per a 192.168.10.10 existeix una ruta més específica (192.168.10.0/24, "En vínculo") que guanya per longest prefix match abans que la mètrica entri en joc; la mètrica només desempata entre rutes igual d'específiques (aquí, entre les dues rutes locals si totes dues interfícies són al mateix /24).

Exercici 3: Cadena de la fallada: (1) el servidor .10 respon a la descàrrega amb paquets grans (1500 bytes, DF activat); (2) el router de València no els pot ficar dins de tun0 (MTU 1436) i els descarta, generant l'ICMP de "fragmentació necessària"; (3) el tallafoc mata aquest ICMP, així que el servidor no se n'assabenta mai i retransmet una vegada i una altra paquets igual de grans → connexió penjada (forat negre de MTU). El ping funciona perquè els seus paquets són petits (desenes de bytes) i caben de sobres al túnel; les pàgines lleugeres, semblant. Solucions: (1) afinar el tallafoc perquè permeti almenys els ICMP de "fragmentació necessària" (no cal obrir tot ICMP), restaurant Path MTU Discovery; (2) activar el MSS clamping als routers del túnel, perquè tots dos extrems negociïn des del handshake segments que càpiguen a la MTU de tun0. (Una tercera via, menys elegant: abaixar la MTU als equips finals.)

La capa d'Internet és el cor de TCP/IP: IP lliura sense garanties, ICMP avisa quan alguna cosa es torça, i la funció d'encaminament — executada per tots els dispositius, no només els routers — decideix cada salt consultant la taula de rutes per prefix més específic i mètrica. Ja saps llegir aquesta taula en els seus dos dialectes (ip route, route print), reconèixer la ruta per defecte com a frontera entre "la meva xarxa" i "el món", i anticipar el xoc entre paquets grans i la MTU del túnel VPN, amb ICMP i l'MSS com a amortidors. També saps què hem ajornat a posta: l'anatomia fina de les adreces i les subxarxes, que omplirà el mòdul 5. Abans, continuem pujant la pila: la parada següent és la capa de transport, on deixarem de moure paquets entre màquines per connectar processos entre si — amb sockets, estats de connexió i les decisions TCP/UDP vistes des del teclat d'un desenvolupador.