Les utilitats de la lliçó anterior treballen sobre resums: ping et dona temps, curl et dona fases, traceroute et dona salts. Però de vegades el resum no basta. Per què aquella connexió triga 3 segons a establir-se? Què està demanant exactament aquell equip al DNS? S'estan perdent paquets dins de la VPN amb Bilbao? Per respondre-ho cal deixar d'inferir i veure els paquets de veritat, un a un, amb les seves capçaleres de cada capa. Això és la captura de trànsit, i les seves dues eines canòniques són Wireshark (gràfica) i tcpdump (terminal). Aquesta lliçó és, a més, la gran recompensa del curs: tot el que has estudiat en abstracte — l'encapsulació del mòdul 2, les capes del 3 i el 4, el three-way handshake — per fi ho veuràs en paquets reals de la xarxa de Meridiano.

⚠️ Advertiment legal i ètic — llegeix-lo abans de capturar res

Capturar trànsit és llegir les comunicacions que passen per una xarxa. Interceptar comunicacions de tercers sense autorització és un delicte (a Espanya, tipificat al Codi Penal, i contrari a l'RGPD quan hi ha dades personals; existeixen equivalents a pràcticament tots els països). Les regles d'aquest curs, i de la teva vida professional, són:

• Captura només en xarxes pròpies o amb autorització explícita del seu responsable. «És el Wi-Fi de la cafeteria i estava obert» no és autorització.
• En una empresa, no n'hi ha prou amb una autorització informal: fes-ho d'acord amb les polítiques internes (autorització del responsable de sistemes/seguretat, registre de l'actuació, propòsit definit).
• Les captures contenen dades personals i credencials: guarda-les xifrades, el temps imprescindible, comparteix-les només amb qui les hagi de veure i esborra-les en tancar la incidència. Un fitxer .pcap oblidat en un escriptori compartit és una fuita de dades.
• Tot el que farem aquí és diagnòstic de la pròpia xarxa de Meridiano, amb autorització: aquest és l'únic context legítim que aquest curs ensenya.

1. Quan capturar: els límits de les utilitats bàsiques
2. Wireshark: instal·lació i anatomia de la interfície
3. El panell de detall ÉS l'encapsulació
4. Filtres de captura davant filtres de visualització
5. Seguir una conversa TCP: el handshake, vist de veritat
6. tcpdump: capturar en un servidor sense interfície gràfica
7. Anàlisi guiada (a): DNS + GET a la intranet, paquet a paquet
8. Anàlisi guiada (b): la videotrucada lenta València–Bilbao

Senyals que toca obrir el capturador:

• El símptoma és de contingut, no de connectivitat: la connexió s'estableix, però l'aplicació es comporta de manera estranya (respostes truncades, capçaleres inesperades, redireccions rares).
• El símptoma és temporal: «triga molt a començar», «es congela a estones». Els temps entre paquets només es veuen capturant.
• Dues eines es contradiuen: ping va bé però l'aplicació va fatal → probablement pèrdua selectiva o retransmissions que el resum no mostra.
• Necessites proves: per escalar al proveïdor de la VPN o a l'ISP, «va lent» no val; una captura amb retransmissions cronometrades, sí.

Regla d'or: la captura és l'últim esglaó, no el primer. És l'eina més potent i la més cara en temps d'anàlisi; arriba-hi amb una hipòtesi formada amb les utilitats de 06-01.

Wireshark és lliure i gratuït (wireshark.org), disponible per a Windows, Linux i macOS. Dos apunts d'instal·lació que convé entendre conceptualment:

• Capturar exigeix accés privilegiat a la targeta de xarxa, que es posa en mode d'escolta. A Windows el proporciona el driver Npcap (s'instal·la amb Wireshark); a Linux, o bé executes amb permisos o (millor) afegeixes el teu usuari al grup wireshark.
• En un switch modern només veuràs el teu propi trànsit i el broadcast (el switch commuta per MAC, mòdul 2, i no et reenvia converses alienes). Per veure el trànsit d'un altre equip — sempre amb autorització — es configura un port mirall (port mirroring/SPAN) al switch, o es captura directament al servidor implicat, que és el que farem amb tcpdump.

En obrir Wireshark tries una interfície (l'Ethernet o el Wi-Fi), prems el botó de captura i la finestra s'organitza en tres panells apilats:

Consell de lectura de la llista: la columna de temps per defecte és relativa a l'inici de la captura; els salts grans entre files consecutives d'una mateixa conversa són el teu primer indicador de «aquí es va encallar».

Atura't en això, perquè és el moment en què el curs «tanca el cercle». Selecciona qualsevol paquet i el panell de detall mostra una cosa com aquesta:

Cada línia desplegable és una capa d'encapsulació, exactament la «nina russa» que vas estudiar al mòdul 2 i que vas formalitzar amb OSI (mòdul 3) i TCP/IP (mòdul 4):

• Frame → la capa física/enllaç vista pel capturador (capa 1: quants bytes van passar pel cable).
• Ethernet II → capa 2: les MAC de la Marta i del servidor de la intranet, la trama del mòdul 2.
• Internet Protocol → capa 3: IP, TTL, fragmentació. Desplega-la i hi veuràs el camp TTL que fas servir des del mòdul 2.
• TCP → capa 4: ports, números de seqüència, flags (SYN, ACK, FIN, RST...), finestra.
• TLS / HTTP / DNS... → capa d'aplicació.

Wireshark no «dibuixa» les capes per didàctica: descodifica el paquet real en aquest ordre perquè així està construït. Quan al mòdul 2 vam dir que HTTP viatja dins de TCP, dins d'IP, dins d'Ethernet, descrivíem literalment aquests quatre desplegables. D'ara endavant, quan dubtis de quina capa fa què, obre una captura: la resposta és al davant.

Una interfície d'oficina genera centenars de paquets per segon; sense filtrar, t'ofegues. Wireshark té dos sistemes de filtratge que els principiants confonen constantment:

Estratègia recomanada per començar: captura ample (com a molt un filtre de captura suau, com el host de la màquina investigada) i filtra en visualització, que és reversible. Un filtre de captura massa agressiu pot descartar just el paquet que explicava el problema (per exemple, filtres port 443 i et perds la consulta DNS fallida que era la causa real).

Filtres de visualització essencials, amb la xarxa de Meridiano:

Es combinen amb && (i), || (o), ! (no). Si la barra del filtre es posa verda, la sintaxi és vàlida; vermella, no ho és (el clàssic: escriure port 443 — sintaxi de captura — on va la de visualització).

Al mòdul 2 vas estudiar el three-way handshake amb un diagrama. Ara, la Marta obre la intranet i capturem al seu PC amb el filtre ip.addr == 192.168.10.10 && tcp:

Línia a línia:

• Paquet 12 — SYN: la Marta (port efímer 52814, mòdul 2) truca al 443 del servidor. Fixa't en l'MSS=1460 anunciat: és l'MSS que vam calcular amb l'MTU al mòdul 4 (1500 − 40).
• Paquet 13 — SYN, ACK: el servidor accepta. Si en lloc d'això hi veiessis un RST, seria el «connection refused» de 06-01: port tancat. Si no hi veiessis res (SYN retransmès diverses vegades), seria el timeout: host caigut o tallafoc que descarta.
• Paquet 14 — ACK: connexió establerta. Tres paquets, tal com prometia el diagrama del mòdul 2 — però ara amb temps: 0,6 ms d'anada i tornada, coherent amb una LAN.
• Paquets 15–16: sobre la connexió ja oberta arrenca TLS. Al Client Hello hi viatja en clar l'SNI (el nom del servidor): és de les poques coses llegibles d'una connexió xifrada.

Dos gestos de Wireshark que has de conèixer:

• Clic dret → Follow → TCP Stream: aïlla aquella conversa completa i, si és trànsit sense xifrar, mostra el diàleg llegible (veuràs un HTTP sencer com a text). Amb HTTPS veuràs dades xifrades — que és precisament la garantia de TLS del mòdul 2.
• Statistics → Conversations: taula de totes les converses de la captura amb bytes i durada; ideal per trobar «qui s'està menjant l'amplada de banda».

El servidor de la intranet (192.168.10.10) és un Linux sense escriptori: allà no hi ha Wireshark. L'eina és tcpdump, que fa servir la mateixa sintaxi BPF dels filtres de captura i requereix privilegis (sudo):

Claus de lectura i d'ús:

• -i eth0: interfície on escoltar; -n: no resoldre noms (més ràpid, i no genera trànsit DNS propi que contamini la captura).
• El filtre port 443 and host 192.168.10.21 va al final, en sintaxi BPF.
• Els flags van abreujats: [S] = SYN, [S.] = SYN+ACK (el punt és l'ACK), [.] = ACK, [F] = FIN, [R] = RST. Aquí hi torna a ser el handshake complet, ara en text pla.
• Altres opcions útils: -c 100 (parar després de 100 paquets), -v (més detall, inclou el TTL), -A (mostrar el contingut en ASCII, útil amb HTTP sense xifrar).

El flux de treball professional combina totes dues eines — capturar on passa, analitzar on s'està còmode:

Recorda l'advertiment inicial: aquest .pcap conté comunicacions reals. Tracta'l com la dada sensible que és.

Reproduïm amb captura el flux complet que vas estudiar al final del mòdul 4: la Marta obre https://intranet.grupomeridiano.example/api/proyectos amb la memòria cau DNS buida. Captura al seu PC, filtre de visualització dns || (ip.addr == 192.168.10.10 && tcp):

Observa el guió, que ja et saps de memòria però que ara té números:

1. DNS (paquets 1–2): pregunta al DNS configurat (el router .10.1), que respon el registre A en 1,8 ms. Va sobre UDP port 53 — comprova-ho desplegant la capa de transport del paquet 1. Si repeteixes la prova, aquests dos paquets desapareixen: la resposta va quedar en memòria cau (el TTL de registre de 06-01 en acció).
2. TCP (3–5): el handshake.
3. TLS (6–8): la salutació criptogràfica. Al paquet 7 pots desplegar i examinar el certificat del servidor.
4. HTTP (9–10): el GET i la seva resposta viatgen com a «Application Data» — xifrats. Saps que allà dins hi va GET /api/proyectos perquè el vas llançar tu, però Wireshark no ho pot (ni ho ha de) llegir.

Temps total: menys de 20 ms. Guarda't mentalment aquesta captura «sana»: és el teu patró de referència per a l'anàlisi següent, on alguna cosa va malament.

Símptoma: les videotrucades entre la Marta (València) i en Jon (Bilbao) es congelen a estones des de fa uns dies; la navegació «sembla» normal. Un ping -t 192.168.20.7 des de València mostra pèrdues ocasionals (2 de cada ~30) i jitter alt — indici, no diagnòstic. Amb l'autorització del responsable de sistemes, capturem al PC de la Marta durant una trucada de prova i una transferència de fitxers simultània cap a Bilbao, i apliquem el filtre:

I a Statistics → TCP Stream Graphs (o simplement comptant amb el filtre): ~3 % dels segments cap a Bilbao són retransmissions, concentrades en ràfegues. Interpretació, recolzada en el que saps de TCP (mòdul 2) i de la VPN (mòdul 4):

• Una retransmissió significa que TCP va enviar un segment i no en va rebre l'ACK a temps: el segment (o el seu ACK) es va perdre pel camí. Els Dup ACK són el receptor dient «em falta un tros, reenvia».
• La navegació «sembla normal» perquè TCP repara la pèrdua retransmetent — pagant latència, que en una web gairebé no es nota. La videotrucada fa servir UDP en temps real: allò perdut no es reenvia (no tindria sentit reenviar un fotograma vell), així que la mateixa pèrdua que TCP dissimula, a la trucada es veu com una congelació. Dos símptomes diferents, una sola causa: pèrdua de paquets al trajecte València–Bilbao.
• On? La captura a la LAN de València mostra que els segments surten; el ping dins de la seu no perd res; la pèrdua apareix només cap a l'altra seu → el problema és a la VPN o a la línia d'Internet que la transporta, no a les LAN. És el mateix raonament de delimitació del traceroute de 06-01, ara amb proves quantificades.
• Tancament del cas: amb la captura com a evidència (3 % de retransmissions en ràfegues, marques de temps), Meridiano obre una incidència amb el seu ISP, que detecta saturació a la línia de València a les hores de les ràfegues. Sense la captura, la conversa hauria estat «va lent» / «per part nostra tot està bé».

• Capturar sense autorització «només per aprendre». No. Practica a la teva pròpia xarxa domèstica o en màquines virtuals. A l'empresa, segueix el procediment encara que tinguis els permisos tècnics per saltar-te'l.
• Confondre les dues sintaxis de filtre. port 443 a la barra de visualització dona error (vermell); tcp.port == 443 en un filtre de captura, també. Captura amb BPF, visualitza amb sintaxi Wireshark.
• Filtrar massa en capturar. Allò descartat no es recupera. Captura ample, filtra en visualització.
• Esperar llegir HTTPS. Veuràs el handshake TLS, l'SNI i mides/temps — que ja és moltíssim per a diagnòstic — però no el contingut. Si necessites el contingut de la teva pròpia aplicació, la via és mirar als extrems (logs del servidor, curl -v), no trencar el xifratge.
• Capturar al lloc equivocat. En un switch no veuràs les converses d'altres equips. Captura a l'extrem implicat (PC o servidor) o demana un port mirall.
• Oblidar el -n a tcpdump. Sense ell, cada IP genera una consulta DNS inversa: la sortida va a batzegades i la teva pròpia captura s'omple de trànsit DNS teu.
• Interpretar qualsevol retransmissió com una catàstrofe. Alguna retransmissió aïllada és vida normal a Internet. Preocupen els percentatges sostinguts (≳1–3 %) i les ràfegues correlacionades amb el símptoma.
• Deixar els .pcap abandonats. Xifrats mentre visquin, esborrats en tancar la incidència.

1. En una captura del PC de l'Ana veus, tres vegades seguides i amb ~1, 2 i 4 segons de separació, el mateix paquet: 192.168.10.24 → 203.0.113.40 TCP [SYN] 51330 → 443. No hi ha cap SYN/ACK ni RST de tornada. Què està passant, quina diferència hi ha amb rebre un RST, i amb quin símptoma d'usuari es correspon?
2. Vols capturar al servidor de la intranet (sense entorn gràfic) tot el trànsit DNS que el mateix servidor genera o rep, desar-lo en un fitxer i analitzar-lo després al teu PC amb Wireshark. Escriu l'ordre de captura i descriu els dos passos següents. Quina condició prèvia no tècnica has de complir abans d'executar res?
3. Durant l'anàlisi de la videotrucada, un company proposa: «filtrem la captura amb tcp.analysis.retransmission des de l'inici, com a filtre de captura, així el fitxer pesa menys». Explica els dos errors de la proposta.

1. És el patró de SYN sense resposta amb retransmissió exponencial: el sistema de l'Ana reintenta el SYN duplicant l'espera (1 s, 2 s, 4 s...) perquè ningú no contesta. O el host 203.0.113.40 està caigut, o — més freqüent — un tallafoc descarta silenciosament el paquet (política drop). La diferència amb un RST és crucial: el RST és una resposta activa («host viu, port tancat» → error immediat connection refused), mentre que el silenci produeix un timeout llarg: l'usuari veu l'aplicació «penjada» 20-30 segons abans de l'error. És la parella «port tancat vs host caigut» del mòdul 3, vista en paquets.
2. Condició prèvia: autorització d'acord amb les polítiques internes (és el servidor de l'empresa i el trànsit DNS revela activitat d'usuaris). Ordre: sudo tcpdump -i eth0 -n port 53 -w /tmp/dns-intranet.pcap (DNS fa servir el port 53; -w desa en format pcap; s'atura amb Ctrl+C o afegint-hi -c N). Passos següents: (1) copiar el fitxer al PC d'anàlisi (per exemple amb scp), (2) obrir-lo amb Wireshark (File → Open) i analitzar-lo amb filtres de visualització (dns). En tancar la incidència, esborrar el .pcap.
3. Primer error, sintacticoconceptual: tcp.analysis.retransmission és un filtre de visualització; els filtres de captura fan servir sintaxi BPF i aquest filtre no hi existeix — de fet no hi pot existir, perquè detectar una retransmissió exigeix comparar cada paquet amb els anteriors del seu flux, i el filtre de captura decideix paquet a paquet, sense memòria. Segon error, metodològic: encara que es pogués, et quedaries només amb les retransmissions i sense el seu context (els paquets originals, els Dup ACK, els temps entre ells), que és just el que permet calcular el percentatge de pèrdua i localitzar-la. Es captura ample i es filtra en visualitzar.

Ja saps baixar al nivell on els paquets no menteixen: Wireshark amb els seus tres panells (i la revelació que el panell de detall és l'encapsulació dels mòduls 2–4), la disciplina dels dos tipus de filtre, el three-way handshake contemplat per fi en paquets reals de la Marta contra la intranet, tcpdump per capturar en servidors i endur-te el .pcap a analitzar amb calma, i dues anàlisis completes: el flux DNS→TCP→TLS→HTTP sa com a patró de referència, i la videotrucada lenta resolta detectant retransmissions a la VPN. I, embolcallant-ho tot, el marc que no és opcional: només en xarxes pròpies o autoritzades, d'acord amb les polítiques de l'empresa, tractant les captures com les dades sensibles que són. Tens les utilitats ràpides (06-01) i el microscopi (06-02); el que falta és el que distingeix el professional de l'aficionat amb eines: un mètode que decideixi què comprovar, en quin ordre i quan parar. Aquest mètode sistemàtic — enfocaments per capes, els 7 passos, l'arbre de decisió i tres incidències de Meridiano resoltes de cap a cap — és la propera i última lliçó del mòdul.