Tot el que has fet en aquest mòdul passava dins de srv-tramontana. Però un servidor només existeix per a qui hi pugui arribar, i quan la Marta escriu «el web de reserves no carrega», cap de les eines anteriors no et serveix per esbrinar on és el tall. Pot ser a la xarxa, a la resolució de noms, al port, a l'aplicació o al mateix navegador de la Marta, i són cinc problemes completament diferents amb cinc solucions diferents.

Aquesta lliçó et dona les eines de diagnòstic i, sobretot, l'ordre en què es fan servir. Aquest ordre és el que separa qui resol una incidència en cinc minuts de qui es passa dues hores tocant coses a l'atzar. Aquí no configurem res: la configuració persistent de xarxa és 06-01, el tallafocs és 06-03 i SSH a fons és 06-02. Aquí es mira, es mesura i es conclou.

1. El repàs mínim imprescindible
2. ip: llegir la configuració real
3. Connectivitat i camí: ping, traceroute, mtr
4. Resolució de noms
5. Ports i sòcols amb ss
6. Provar serveis: curl, wget, nc
7. Què et diu cada eina quan «el web no va»
8. Transferència: scp i rsync sobre SSH
9. Amplada de banda amb iperf3
10. Metodologia de diagnòstic per capes
11. Cas Tramontana: «el web de reserves no carrega»

El just per entendre la sortida de les ordres, no un curs de xarxes.

• Capes. Les dades viatgen encapsulades: l'aplicació (HTTP) va dins de transport (TCP/UDP), que va dins de xarxa (IP), que va dins d'enllaç (Ethernet). Cada eina mira una capa diferent, i per això el diagnòstic es fa de baix a dalt.
• IP, màscara i CIDR. 10.0.2.15/24 significa que els tres primers octets identifiquen la xarxa i l'últim l'amfitrió. Tot el que sigui a 10.0.2.x és abastable directament; per a la resta cal un intermediari.
• Passarel·la (gateway). Aquest intermediari: l'adreça a la qual s'envia tot el que no és local.
• DNS. Tradueix noms a adreces. És una capa a part i falla pel seu compte, cosa que explica el clàssic «el navegador no va però el ping a la IP sí».
• Ports. Un número de 16 bits que identifica el servei dins d'una màquina: 22 SSH, 80 HTTP, 443 HTTPS, 5432 PostgreSQL, 8080 el de la nostra aplicació. Per sota de 1024 requereixen privilegis per obrir-se.
• TCP enfront d'UDP. TCP estableix connexió, garanteix l'ordre i reenvia el que s'ha perdut; és el que fa servir el web. UDP dispara i oblida; el fan servir DNS i la reproducció en temps real. La diferència importa en diagnosticar: en TCP hi ha estats observables, en UDP no hi ha res per mirar.

ip substitueix ifconfig, route i arp, que porten més d'una dècada obsolets i poden no estar ni instal·lats.

-brief dona la vista compacta que vols el 90 % de les vegades: interfície, estat i adreces. lo és el bucle local; enp0s3 és la targeta de la VM, UP i amb la 10.0.2.15/24 que coneixes des del Mòdul 1.

Dues rutes. La segona diu que la xarxa 10.0.2.0/24 és directament abastable. La primera, default, és la passarel·la: tot el que no sigui local surt per 10.0.2.2, que en una VM amb NAT de VirtualBox és el mateix amfitrió fent d'encaminador. proto dhcp indica que la configuració la va donar un servidor DHCP, no un fitxer.

-s link dona els comptadors: errors i dropped diferents de zero apunten a un problema físic o de saturació, i aquí són a zero. ip neigh és la taula ARP —quines adreces MAC hem resolt— i REACHABLE confirma que parlem amb la passarel·la ara mateix, sense necessitat d'enviar ni un ping.

Tres dades: el TTL (64 suggereix un Linux a un salt), el temps d'anada i tornada i la pèrdua. Falta la resposta 2.

Per què un ping perdut no sempre és una fallada. ICMP és el trànsit de menor prioritat de la xarxa: els equips el descarten tan bon punt tenen coses més importants a fer, i molts tallafocs el bloquegen del tot. Un 33 % de pèrdua sobre tres paquets tampoc no és estadísticament res. Conseqüències pràctiques:

• Que el ping falli no demostra que l'amfitrió estigui caigut. Pot estar filtrat.
• Que el ping funcioni no demostra que el servei funcioni. La màquina respon; l'aplicació pot ser morta.
• Una pèrdua ocasional en ICMP no implica pèrdua en TCP.

ping respon una sola pregunta: «hi ha camí IP fins allà?». Res més. Amb -c limites els paquets, amb -i 0.2 escurces l'interval i amb -M do -s 1472 pots diagnosticar problemes de MTU.

Cada línia és un salt. -n evita la resolució inversa i accelera molt la sortida. Els asteriscos del salt 3 signifiquen que aquell equip no respon, no que el camí es talli allà: si els salts posteriors sí que contesten, simplement aquell encaminador ignora el trànsit de diagnòstic. tracepath fa el mateix sense privilegis i descobreix la MTU del camí.

mtr combina ping i traceroute en temps real i és la millor eina per a pèrdues intermitents: mtr -rwc 100 desti envia cent paquets i dona un informe amb el percentatge de pèrdua i la latència de cada salt, que és com es distingeix un problema propi d'un del proveïdor.

L'ordre el fixa /etc/nsswitch.conf:

files significa /etc/hosts primer. Per això una entrada oblidada allà guanya a qualsevol DNS del món i produeix incidències desconcertants: la màquina resol un nom a una IP que ja no existeix i cap canvi al DNS no ho arregla. Quan un nom resol malament, mira /etc/hosts abans que res.

Detall important: dig no consulta /etc/hosts, va directe al DNS. És exactament el que vols per distingir «el DNS està malament» de «algú va tocar /etc/hosts». Les seccions de la resposta són QUESTION (què s'ha preguntat), ANSWER (la resposta, amb el seu TTL en segons), AUTHORITY i ADDITIONAL.

dig @1.1.1.1 enfront de dig a seques és el diagnòstic decisiu: si un servidor extern resol i el teu no, el problema és el teu resolutor, no el domini.

ss substitueix netstat i és l'eina central d'aquesta lliçó.

Opció per opció:

La columna Local Address és la que més informació dona i la que menys gent llegeix:

Mira l'última línia de la sortida de dalt. executable escolta a 127.0.0.1:8080. Guarda't aquesta dada.

TIME-WAIT mereix explicació perquè espanta sense motiu: després de tancar una connexió, l'extrem que va tancar primer manté el sòcol uns 60 segons per si arriba algun paquet endarrerit. Milers de TIME-WAIT en un servidor amb trànsit són normals. Molts CLOSE-WAIT, en canvi, sí que són un símptoma: signifiquen que l'aplicació no tanca els seus sòcols, i això acaba esgotant descriptors.

netstat -tulpn fa el mateix i encara el veuràs en documentació antiga; és al paquet net-tools, que ja no s'instal·la per defecte. Escriu ss.

Aquesta ordre d'una línia és la que faràs servir més: -s silencia la barra de progrés, -o /dev/null descarta el cos i -w imprimeix just el que t'interessa. Un codi i un temps.

--resolve és l'opció que resol més incidències de les que sembla: permet provar el servidor abans de tocar el DNS, o comprovar si el problema és de resolució sense canviar res.

«Connection refused» és un missatge molt informatiu: significa que el paquet va arribar i la màquina va contestar activament que allà no hi ha ningú escoltant. No és un tallafocs —això donaria un temps d'espera esgotat— ni un problema de ruta.

nc comprova un port sense més cerimònia, i wget descarrega fitxers (-c reprèn, -r recursiu, -O - aboca a stdout):

Dues proves gairebé idèntiques amb resultats oposats. Això és una troballa, i confirma el que ja vam veure a ss.

telnet host port continua servint com a últim recurs per parlar a mà amb un servei de text, però nc i curl ho fan millor i són més presents.

La lectura important de la taula: cada eina descarta una capa. No serveixen per «provar coses»; serveixen per eliminar hipòtesis en ordre.

scp copia i prou. rsync és superior en gairebé tot: transfereix només les diferències, comprimeix amb -z, conserva permisos amb -a, mostra el progrés amb --progress i —l'essencial segons la convenció del curs— admet --dry-run per veure què faria abans de fer-ho. Ja el feies servir en local des de 02-04; sobre SSH funciona igual, només canvia que el destí porta usuari@host:.

ping mesura latència, no capacitat. Per mesurar el cabal real cal generar trànsit: en un extrem iperf3 -s i a l'altre iperf3 -c <servidor> -t 10. L'informe dona els Mbit/s assolits i, amb -u, la pèrdua i el jitter en UDP. És la manera de respondre amb dades a «la xarxa va lenta», que gairebé sempre resulta ser una altra cosa.

Aquest és l'apartat que cal recordar. S'avança de baix a dalt i no se salta cap pas.

Tres regles que acompanyen el diagrama:

1. Anota el resultat de cada pas. Un diagnòstic és una cadena de descarts, i sense registre acabes repetint proves.
2. No canviïs res mentre diagnostiques. Si toques la configuració a mitges, ja no saps què va causar què.
3. Prova des dels dos costats. Que funcioni al servidor i no des de fora acota el problema millor que qualsevol altra prova.

13:05. Missatge de la Marta. Apliquem el procediment.

Pas 1: IP i ruta? ip -brief a dona enp0s3 UP 10.0.2.15/24 i ip r mostra la ruta per defecte via 10.0.2.2. Correcte.

Pas 2: passarel·la?

Sense pèrdua i amb latència de dècimes de mil·lisegon. Correcte.

Pas 3: resol el nom?

getent hosts és millor que dig per a aquesta pregunta: consulta pel mateix camí que les aplicacions, respectant /etc/nsswitch.conf, així que inclou /etc/hosts. Resol a 10.0.2.15, que és la IP correcta. Correcte.

Pas 4: escolta el port?

Aquí està. El procés escolta, però a 127.0.0.1:8080: només accepta connexions des de la mateixa màquina. Des del portàtil de la Marta és inabastable, i cap tallafocs ni cap DNS no hi tenen res a veure.

Pas 5: confirmar-ho des dels dos costats.

Diagnòstic tancat: l'aplicació funciona perfectament i està escoltant a la interfície equivocada. Respon 200 pel bucle local i refusa la connexió per la seva pròpia IP.

La causa. El procés es va reiniciar ahir a la nit, i app.conf no fixa l'adreça d'escolta, de manera que l'aplicació va fer servir el seu valor per defecte. Abans del reinici portava mesos funcionant perquè algú l'havia arrencada a mà amb un paràmetre que no va quedar registrat enlloc. És el patró exacte contra el qual et prevenia 03-06: un servei llançat a mà no sobreviu a un reinici amb la mateixa configuració.

La solució és afegir l'adreça d'escolta a /etc/tramontana/app.conf amb la convenció de sempre —còpia .bak-$(date +%F), sed -i, diff -u— i reiniciar el procés amb SIGTERM i espera. La solució definitiva, que la configuració quedi fixada en una unitat de servei que arrenqui sola i sempre igual, és systemd i és 05-05.

Informe per a la Marta. El servei no va deixar de funcionar mai: continuava atenent peticions, però només des del mateix servidor, perquè després del reinici d'ahir a la nit va arrencar escoltant únicament a la seva adreça interna. Ja està corregit al fitxer de configuració, de manera que el proper reinici conservarà l'ajust. Això protegeix que la incidència es repeteixi per la mateixa causa. No protegeix davant de dues coses: ningú no ens va avisar del tall —ho vam detectar perquè tu ho vas dir, no per un sistema de vigilància—, i el servei continua arrencant-se d'una manera que depèn que algú ho faci bé. Totes dues coses tenen solució coneguda —monitoratge i gestió de serveis— i proposo abordar-les al mòdul següent.

• Concloure «està caigut» perquè el ping falla. ICMP es filtra constantment. Prova el port amb nc o curl.
• Concloure «funciona» perquè el ping respon. La màquina respon; el servei pot ser mort.
• Provar només des del servidor. curl a 127.0.0.1 funciona fins i tot amb el servei mal enllaçat. Prova també per la IP real.
• Ignorar la columna Local Address d'ss. 127.0.0.1:port enfront de 0.0.0.0:port és la diferència entre accessible i inaccessible.
• Oblidar /etc/hosts. Guanya al DNS i produeix incidències impossibles d'explicar mirant només el DNS.
• Fer servir dig per saber com resol una aplicació. dig ignora /etc/hosts; fes servir getent hosts.
• Alarmar-se pels TIME-WAIT. Són normals. Els CLOSE-WAIT acumulats sí que són un símptoma.
• Tocar la configuració a mitja investigació. Diagnostica primer, canvia després, i només una cosa cada vegada.
• Consell: curl -w '%{http_code} %{time_namelookup} %{time_connect} %{time_total}\n' reparteix el temps total entre DNS, connexió i resposta. Amb una sola ordre saps quina fase és la lenta.
• Consell: guarda la sortida d'ip a, ip r i ss -tulpn d'un servidor quan funciona bé. Comparar amb diff -u contra l'estat actual és el diagnòstic més ràpid que existeix.

Exercici 1. Documenta la configuració de xarxa completa de la teva VM: interfícies amb el seu estat i adreça, passarel·la, servidors DNS i comptadors d'error. Guarda-ho a /home/operador/dades/xarxa-referencia.txt amb la data, i explica per a què servirà aquell fitxer.

Exercici 2. Comprova si el servei de l'aplicació és accessible des d'una altra màquina sense sortir del servidor, i explica per què curl http://127.0.0.1:8080/ no respon aquesta pregunta. Indica quina ordre et dona la resposta definitiva i per què.

Exercici 3. Aplica la metodologia de diagnòstic a aquest cas: des de portatil-alumne, ping srv-tramontana respon, però el navegador es queda carregant indefinidament en obrir http://reserves.tramontana.example:8080/. Enumera les comprovacions en ordre, amb l'ordre de cadascuna, i digues quina conclusió trauries de cada resultat possible.

Solució 1.

Les claus agrupen diverses ordres per redirigir tota la sortida del bloc amb un únic >, com vas aprendre a 03-04. La seva utilitat és la de l'últim consell: quan d'aquí a tres mesos alguna cosa deixi de funcionar, un diff -u xarxa-referencia.txt <(ip -brief a) et dirà en un segon què ha canviat, que és la pregunta que de debò importa en una incidència. Un servidor documentat quan funciona es diagnostica en minuts; un sense referència, a base de conjectures.

Solució 2.

curl http://127.0.0.1:8080/ no respon la pregunta perquè el bucle local és un camí diferent: el trànsit ni tan sols surt per la interfície de xarxa, així que funciona encara que el servei estigui enllaçat només a 127.0.0.1. És la prova que més falsos «doncs a mi em funciona» genera.

L'ordre definitiva és ss -tulpn, i concretament la seva columna Local Address: 127.0.0.1:8080 diu, sense ambigüitat i sense dependre de cap altra màquina, que el servei no pot ser accessible des de fora. curl contra la IP real ho confirma empíricament, però ss et dona la causa a més del símptoma.

Solució 3. El detall clau de l'enunciat és que el navegador es queda carregant en comptes de donar un error immediat. «Connection refused» és ràpida; un temps d'espera llarg apunta que els paquets es perden sense resposta, cosa que suggereix filtratge abans que servei caigut. Amb aquesta hipòtesi, l'ordre:

1. ping srv-tramontana — ja sabem que respon: hi ha IP i ruta, capes 1 a 3 descartades.
2. getent hosts reserves.tramontana.example des del portàtil. Si resol a una IP diferent de 10.0.2.15, aquí està la fallada i s'ha acabat. Si resol bé, continuem.
3. nc -zv 10.0.2.15 8080 des del portàtil. Distingir les tres respostes és el que importa: succeeded significa que el port és abastable i el problema és a la capa HTTP; Connection refused significa que ningú no escolta o que escolta només en local; i un bloqueig sense resposta fins a esgotar el temps és la signatura d'un tallafocs descartant paquets en silenci, que és el que encaixa amb el símptoma descrit.
4. sudo ss -tulpn | grep 8080 al servidor, per saber si escolta i en quina adreça. Si és 0.0.0.0:8080, el servei està bé i el tall és intermedi.
5. curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' http://10.0.2.15:8080/ des del servidor. Si respon 200 i des de fora no arriba res, queda confirmat que el problema és entre les dues màquines.
6. Comparar la vista de xarxa de la VM amb la de referència de l'exercici 1.

Conclusió més probable donat el símptoma: un filtratge al camí, sigui el tallafocs del servidor o la configuració de xarxa de la VM. I aquí hi ha el límit honest d'aquesta lliçó: el diagnòstic arriba fins a identificar que el tall és de filtratge; corregir-lo és matèria de 06-01 i 06-03. Saber on acaba el teu diagnòstic i dir-ho amb claredat val més que aventurar una solució que no pots justificar.

Tanques el Mòdul 3 amb la capacitat de mirar cap enfora del servidor i dir, amb proves, on és el problema.

• Tens el repàs mínim —capes, CIDR, passarel·la, DNS, ports, TCP enfront d'UDP— suficient per llegir la sortida de qualsevol d'aquestes eines.
• Llegeixes la configuració real amb ip: -brief a per a interfícies, ip r per a la ruta per defecte, -s link per als comptadors d'error i ip neigh per a la taula ARP.
• Fas servir ping sabent que respon una sola pregunta, i que ni una fallada prova que alguna cosa estigui caiguda ni un èxit prova que el servei funcioni; recorres el camí amb traceroute i persegueixes pèrdues intermitents amb mtr.
• Entens l'ordre de resolució de /etc/nsswitch.conf, saps que /etc/hosts guanya al DNS, llegeixes les seccions d'una resposta de dig i coneixes la diferència crucial entre dig i getent hosts.
• Desglosses ss -tulpn opció per opció, i sobretot llegeixes la columna Local Address, que distingeix un servei accessible d'un d'enllaçat només al bucle local; interpretes els estats TCP sense alarmar-te pels TIME-WAIT.
• Proves serveis amb curl —-I, -v, -w '%{http_code}', --resolve—, amb nc i amb wget, i transfereixes amb scp i rsync sobre SSH.
• I tens una metodologia per capes —IP?, passarel·la?, DNS?, port?, servei?— que has aplicat a un cas real fins a trobar una aplicació escoltant a 127.0.0.1, amb l'informe corresponent per a la Marta i l'honestedat d'assenyalar què queda sense cobrir.

Fes balanç del mòdul sencer. Hi vas arribar sabent executar ordres i te'n vas sabent-les compondre: has modelat el teu entorn amb variables, àlies i historial; has après a descriure conjunts de fitxers amb comodins i patrons de text amb expressions regulars, tenint clar qui expandeix què; has interrogat un servidor amb find, locate i grep fins a trobar una credencial exposada; has entès per on circula cada byte amb les canonades i la redirecció; has convertit acces.log i reserves.csv en informes amb sort, uniq, sed i awk; has diagnosticat una aplicació bloquejada per una còpia de seguretat que saturava el disc; has reprogramat aquella còpia amb bloqueig, prioritat i registre; i acabes de localitzar un servei escoltant a la interfície equivocada. Això és exactament el que anunciava la filosofia Unix del Mòdul 1, ara a les teves mans.

I també has topat diverses vegades amb el mateix mur. La línia de crontab de l'últim exercici acumulava escapades fins a tornar-se il·legible. La canonada de l'informe de facturació ja no cabia en una pantalla. Cada procediment que has dissenyat —comprovar abans d'esborrar, copiar abans d'editar, verificar el resultat— depenia que tu te'n recordessis, pas a pas, sense equivocar-te, a les tres de la matinada. Al Mòdul 4: Scripting en Shell aquell mur desapareix. Aprendràs a guardar els teus procediments en fitxers amb nom, amb variables, arguments i estructures de control; a escriure funcions reutilitzables; a depurar amb set -x i a blindar els teus scripts amb set -euo pipefail i una gestió d'errors seriosa; i a arribar fins als scripts de producció, inclòs el de còpia de seguretat que portes tres lliçons prometent. Tot el que has après aquí és el vocabulari; el Mòdul 4 és la gramàtica que et permet escriure-hi. Actualitza la instantània de la teva VM i ens hi veiem.