Al Mòdul 3 vas aprendre a mirar la xarxa: ip a, ping, dig, ss -tulpn, curl -v i una metodologia per capes per esbrinar per què alguna cosa no respon. Allò era diagnòstic, i el diagnòstic és lectura. Aquesta lliçó fa el pas següent i força més compromès: escriure. Decidiràs l'adreça IP de srv-tramontana, la seva passarel·la, els seus servidors DNS i les seves rutes, i ho deixaràs escrit de manera que sobrevisqui a un reinici.

Compromès és la paraula exacta: configurar la xarxa d'una màquina a la qual accedeixes per la xarxa és l'única tasca d'administració en què un error d'una lletra et deixa fora de manera instantània i sense avís. Per això, a més de la sintaxi de netplan, aquesta lliçó t'ensenya el procediment: validar abans d'aplicar, tenir una reversió automàtica i no deixar mai anar la consola de la VM. srv-tramontana continua amb la configuració que va deixar l'instal·lador —DHCP pur—, així que la seva IP depèn d'un servidor que no controles. Una aplicació de reserves el nom de servei de la qual apunta a 10.0.2.15 no es pot permetre que aquella adreça canviï un dimarts a la nit.

1. Repàs operatiu: IPv4, màscara, CIDR i xarxes privades
2. IPv6 avui: link-local, SLAAC i per què no el desactives
3. Configuració efímera amb ip i per què es perd
4. Netplan: el model de renderers a Ubuntu 24.04
5. El YAML de netplan, camp a camp
6. netplan try i els permisos 600
7. Resolució de noms: systemd-resolved i l'stub 127.0.0.53
8. El nom de la màquina: hostnamectl i /etc/hosts
9. Interfícies: noms predictibles, àlies, VLAN, bonding i ponts
10. Rutes, mètriques i ip route get
11. Reenviament de paquets i NAT com a conceptes
12. Cas Tramontana: de DHCP a IP estàtica, verificat

Una adreça IPv4 són 32 bits en quatre octets. La màscara els parteix en dos: la part de xarxa (bits a 1) i la d'amfitrió (bits a 0). La notació CIDR escriu la màscara com el nombre de bits a 1.

De cada xarxa, dues adreces no són assignables: la de xarxa (tots els bits d'amfitrió a 0, 10.0.2.0) i la de difusió (tots a 1, 10.0.2.255). D'aquí ve el «−2».

Les xarxes privades de la RFC 1918 no s'encaminen a Internet: 10.0.0.0/8 (empreses, VirtualBox NAT, núvols), 172.16.0.0/12 (Docker fa servir 172.17.0.0/16) i 192.168.0.0/16 (encaminadors domèstics). La passarel·la és l'adreça de l'encaminador dins de la teva pròpia xarxa a la qual s'envia tot el que no és local: srv-tramontana és a 10.0.2.15/24, parla directament amb qualsevol 10.0.2.x i lliura la resta a 10.0.2.2.

Per a les IP externes fem servir sempre els rangs de documentació de la RFC 5737: 192.0.2.0/24, 198.51.100.0/24 i 203.0.113.0/24. No facis servir mai adreces reals alienes en exemples ni en proves.

IPv6 va deixar de ser «el futur» fa més d'una dècada i Ubuntu 24.04 el porta actiu.

• Tota interfície operativa té una adreça link-local fe80::/10. No s'encamina fora del segment, però la fan servir el descobriment de veïns (NDP, l'equivalent d'ARP) i els anuncis d'encaminador.
• SLAAC (autoconfiguració sense estat) permet que un amfitrió es construeixi la seva adreça global a partir del prefix que anuncia l'encaminador, sense DHCP. És el normal en IPv6; DHCPv6 existeix i hi conviu.

Només hi ha link-local perquè la xarxa NAT de VirtualBox no anuncia cap prefix IPv6. Desactivar IPv6 «per si de cas» és mala idea, encara que mig Internet ho recomani: no redueixes la superfície d'atac, la redueixes malament. Si un servei escolta a :: i tu desactives IPv6 a mitges, acabes amb regles de tallafocs que no cobreixen un camí que continua existint. A més trenques programari que assumeix ::1 —systemd-resolved inclòs— amb temps d'espera difícils de diagnosticar. La postura correcta és la mateixa que amb IPv4: si està actiu, protegeix-lo; per això el tallafocs de 06-03 farà servir table inet, que cobreix les dues famílies. I si de debò no el necessites en un segment, desactiva'l de manera explícita a netplan (accept-ra: false, link-local: []), no amb un pedaç a mitges.

L'ordre ip no només llegeix: també escriu. I el que escriu viu només al nucli, a memòria.

Fixa't que ip addr add afegeix, no substitueix: una interfície pot tenir diverses adreces alhora. I tot això desapareix en reiniciar, i també tan bon punt systemd-networkd reconfigura la interfície després d'un netplan apply. No hi ha cap fitxer implicat: l'estat de xarxa del nucli és volàtil per disseny. Això converteix ip en l'eina perfecta per provar una hipòtesi i en la pitjor possible per configurar un servidor.

Ubuntu va unificar la configuració de xarxa a netplan: tu escrius YAML declaratiu i netplan genera la configuració del rerefons que toqui.

El renderer networkd és el d'Ubuntu Server —màquines fixes, servidors, núvol— i NetworkManager el d'Ubuntu Desktop, pensat per a portàtils amb wifi, itinerància i VPN d'usuari. A srv-tramontana és networkd.

Els fitxers viuen a /etc/netplan/ amb extensió .yaml, es llegeixen en ordre alfabètic i els últims guanyen sobre els primers. Per això es numeren:

Aquell fitxer el va escriure cloud-init durant la instal·lació i el pot reescriure en el següent arrencada. La manera neta de prendre'n el control és desactivar aquella part:

La sintaxi YAML que trenca tothom: la indentació és amb espais, mai amb tabuladors, i dos espais per nivell és la convenció. Un tabulador produeix un error tan críptic com found character '\t' that cannot start any token. Tres clàssics més: els dos punts necessiten un espai al darrere (dhcp4: false, no dhcp4:false); les llistes s'escriuen amb - o entre claudàtors, però no a mitges; i yes/no s'interpreten com a booleans, així que fes servir sempre true/false.

netplan generate tradueix el YAML a fitxers de systemd-networkd a /run sense activar-los. Si falla, no has tocat la xarxa:

Aquesta és l'ordre que separa qui ha perdut un servidor de qui no.

netplan try aplica la configuració, engega un compte enrere de 120 segons i espera el teu ENTER. Si has trencat la xarxa i la teva sessió SSH es talla, no pots prémer res: en esgotar-se el termini, netplan restaura la configuració anterior. Ajusta el termini amb --timeout 300 si el canvi és delicat.

netplan try no cobreix tots els casos: reverteix bé si el procés continua viu esperant el teu ENTER, però no si el sistema es penja. Per això la regla completa és try més consola de la VM oberta en una altra finestra; a VirtualBox aquella consola no passa per la xarxa.

Des de la 24.04, netplan avisa si els seus fitxers són llegibles per altres: Permissions for /etc/netplan/50-cloud-init.yaml are too open. La raó és directa: un fitxer de netplan pot contenir la contrasenya d'una xarxa wifi o credencials 802.1X en clar, i amb 644 les llegiria qualsevol usuari, inclòs becari. Aplica umask 027 i deixa'ls en 600 root:root.

/etc/resolv.conf és un enllaç simbòlic a un fitxer generat, i l'únic servidor que hi apareix és 127.0.0.53: l'stub local de systemd-resolved. Les aplicacions pregunten a l'stub i l'stub reenvia als DNS reals que li ha lliurat netplan. Editar-lo a mà no serveix de res: es regenera en la següent arrencada o netplan apply.

Tres coses que importen d'aquella sortida:

• El DNS es configura per interfície. Una màquina amb dues interfícies pot tenir DNS diferents a cadascuna, i +DefaultRoute marca quin es fa servir per al que no encaixi en un domini concret.
• DNS Domain és el domini de cerca: amb ell, resolvectl query reserves completa a reserves.tramontana.example.
• resolvectl té en compte /etc/hosts; dig no, perquè parla directament amb el servidor. Aquella discrepància explica el 90 % dels «però si dig ho resol bé». I resolvectl flush-caches buida la memòria cau quan acabes de canviar un registre i continues veient l'antic.

Hi ha tres noms: l'estàtic (el de /etc/hostname, el que persisteix), el transitori (el que pot imposar el DHCP) i el bonic (--pretty, text lliure). /etc/hosts ha de ser coherent, perquè molts programes resolen el seu propi nom en arrencar:

La línia 127.0.1.1 és una convenció de Debian/Ubuntu perquè el nom resolgui fins i tot sense xarxa.

enp0s3 no és arbitrari: és un nom predictible generat per systemd a partir de la posició física del dispositiu — en (ethernet) + p0 (bus PCI 0) + s3 (ranura 3). El sistema antic (eth0, eth1) numerava segons l'ordre de detecció del nucli, que podia canviar entre arrencades i deixar-te el cable de gestió a la interfície equivocada.

Un àlies d'IP és simplement una segona adreça a la mateixa interfície: n'hi ha prou d'afegir-la a addresses. Serveix per migrar un servei d'una IP a una altra sense tallar. I aquesta és la vista general de les interfícies virtuals que veuràs tan bon punt surtis del laboratori, sense muntar-les aquí:

La VPN apareix aquí només com a concepte de xarxa: el servidor WireGuard complet es munta al projecte 08-04.

Dues entrades: la ruta per defecte i la ruta d'enllaç de la pròpia xarxa, que el nucli crea tot sol en assignar l'adreça. El nucli tria sempre la ruta més específica (el prefix més llarg) i, en igualtat, la de mètrica menor. Una ruta estàtica persistent s'afegeix al bloc routes del YAML amb to: 198.51.100.0/24 i via: 10.0.2.9.

L'eina d'or per no discutir és preguntar al nucli què farà amb un paquet concret, sense enviar res:

La primera surt per l'encaminador 10.0.2.9 segons la ruta estàtica; la segona és local i no passa per cap encaminador. Quan algú afirmi «és que el trànsit no va per on ha d'anar», ip route get tanca la conversa en un segon.

Per defecte, Linux no reenvia paquets entre interfícies: si n'arriba un que no va adreçat a ell, el descarta. Ho controla un paràmetre del nucli, i activar-lo converteix la màquina en un encaminador:

Es fa de manera persistent a /etc/sysctl.d/, mai editant /etc/sysctl.conf a mà. NAT és el que fa l'encaminador de casa teva i el que fa VirtualBox amb la xarxa 10.0.2.0/24: reescriu l'adreça d'origen dels paquets sortints perquè tots semblin venir d'una sola IP, i manté una taula per tornar les respostes. NAT no és seguretat, encara que ho sembli: és un apedaçament per a l'escassetat d'IPv4 que, de propina, fa que les connexions entrants no arribin a ningú per defecte.

srv-tramontana no necessita ni reenviament ni NAT: és un servidor final, i deixar ip_forward = 0 és la postura correcta. L'activaràs amb la VPN del projecte 08-04. Les regles de filtratge i NAT s'escriuen amb ufw/nftables, i això és la lliçó 06-03.

Pas 0 — mesurar abans i fer còpia, la convenció del curs:

Pas 1 — obrir la consola de la VM a VirtualBox i deixar una segona sessió SSH oberta. No tanquis mai la porta per la qual estàs entrant.

Pas 2 — escriure la configuració:

El fitxer de cloud-init es retira fora de /etc/netplan/: no n'hi ha prou de reanomenar-lo dins del directori, perquè netplan llegeix qualsevol .yaml.

Pas 3 — validar sense aplicar: sudo netplan generate i comprovar que retorna 0.

Pas 4 — aplicar amb xarxa de seguretat: sudo netplan try. Abans de prémer ENTER, comprova des de l'altra sessió que continues tenint accés i que l'aplicació respon. Només aleshores acceptes.

Pas 5 — mesurar després i comparar:

L'única cosa que ha canviat és el que volíem: la ruta passa de proto dhcp a proto static i apareix el domini de cerca. La IP és la mateixa i els serveis escolten igual. Si el diff mostrés res més, tindries un problema per investigar ara, no d'aquí a tres setmanes.

Pas 6 — la prova de foc, reiniciar:

Una configuració de xarxa no està acabada fins que sobreviu a un reinici. Documenta el canvi a /opt/tramontana/HISTORIAL, com tota la resta.

• Tabuladors al YAML. És, de bon tros, l'error número u. Configura el teu editor perquè als .yaml insereixi espais (:set expandtab a vim) i executa sempre netplan generate abans d'aplicar.
• Oblidar el CIDR a addresses. - 10.0.2.15 sense /24 dona un error de validació poc clar. L'adreça sempre porta la seva màscara.
• Fer servir netplan apply en una màquina remota. Si t'equivoques, només la recuperes per consola física o de l'hipervisor. netplan try costa el mateix i perdona.
• Editar /etc/resolv.conf. És un enllaç a un fitxer generat: el teu canvi dura fins a la següent arrencada. El DNS es canvia a netplan i es comprova amb resolvectl status.
• Deixar actiu el fitxer de cloud-init. Pot reescriure la teva configuració en arrencar; desactiva'l amb 99-disable-network-config.cfg.
• Assignar una IP estàtica dins del rang del DHCP. Tard o d'hora el servidor DHCP la dona a un altre i tens un conflicte intermitent i desesperant. Demana una reserva o un rang exclòs.
• Consell: guarda /etc/netplan/ a git juntament amb els teus scripts. És configuració de producció i mereix historial, igual que les unitats de systemd.

Advertiment de seguretat i compliment: un canvi d'adreçament en un servidor que tracta dades personals d'hostes afecta regles de tallafocs, llistes de control d'accés i registres d'auditoria. En un entorn real es planifica amb finestra de manteniment, es comunica a les persones responsables i ho revisa el responsable de seguretat. No reconfiguris ni escanegis mai xarxes que no siguin teves: aquí tot es fa sobre srv-tramontana, la teva pròpia VM.

1. Doble comprovació abans d'aplicar. Escriu la seqüència exacta d'ordres per canviar el DNS de srv-tramontana de 10.0.2.2 a 192.0.2.53, des d'una sessió SSH, sense arriscar-te a perdre la resolució de noms. Inclou-hi la verificació posterior.
2. Segona adreça i ruta estàtica. Afegeix a enp0s3 l'adreça 10.0.2.16/24 i una ruta cap a 198.51.100.0/24 a través de 10.0.2.9, de manera persistent. Després demostra, sense generar trànsit real, que un paquet a 198.51.100.7 sortirà per aquella ruta i no per la de defecte.
3. Diagnòstic d'un YAML trencat. En aplicar la teva configuració obtens Error in network definition: enp0s3: unknown key 'gateway4'. Explica què ha passat, corregeix-ho i digues per què netplan no ha deixat la màquina sense xarxa.

1. Un DNS que no respon deixa la màquina «funcionant i muda», així que es tracta amb el mateix procediment que la IP:

Verificació des de la sessió de seguretat, abans de prémer ENTER:

Dos detalls: la còpia va a /root i no a /etc/netplan/, perquè qualsevol fitxer .yaml d'aquell directori es llegeix (amb .bak-data no ho seria, però és millor no dependre'n); i si el DNS nou no respongués, netplan try reverteix tot sol als 120 segons.

2. S'afegeix l'adreça a la llista i la ruta al bloc routes:

ip route get interroga la taula de rutes del nucli sense enviar cap paquet: és la demostració exacta que demanava l'enunciat. Si hagués retornat via 10.0.2.2, la ruta estàtica no s'hauria aplicat.

3. gateway4 era la clau clàssica per a la passarel·la i està eliminada a les versions de netplan d'Ubuntu 24.04. El seu substitut és una entrada a routes:

El canvi es va fer perquè gateway4 només permetia una passarel·la i no admetia mètriques ni taules alternatives; routes cobreix tots els casos amb la mateixa sintaxi. I la màquina no s'ha quedat sense xarxa perquè l'error el va detectar l'analitzador de netplan a la fase de generate, abans de tocar res: la configuració només arriba al nucli si el YAML és vàlid en la seva totalitat. Aquest és exactament el motiu pel qual netplan generate va sempre abans que netplan try: separa els errors de sintaxi (barats) dels de contingut (cars).

srv-tramontana ja no depèn d'un servidor DHCP per tenir l'adreça que el seu propi nom de servei anuncia. Has deixat la xarxa escrita, versionada i verificada: un fitxer de netplan amb permisos 600, IP estàtica 10.0.2.15/24, passarel·la 10.0.2.2, DNS i domini de cerca declarats, resolució a través de systemd-resolved i un procediment —mesurar, generate, try, comparar amb diff -u, reiniciar— que pots repetir en qualsevol màquina sense suar. Pel camí has vist per què ip serveix per provar i no per configurar, per què IPv6 es protegeix en comptes de desactivar-se, i com preguntar al nucli per on sortirà un paquet concret.

Però fixa't en el que acabes de fer: has fixat una adreça estable i ben coneguda per a un servidor que accepta connexions SSH amb contrasenya, permet entrar com a root i ja acumula 47 intents fallits des de 203.0.113.44 a /var/log/btmp. Li has posat una bústia permanent a una porta que no té pany. A la lliçó següent, 06-02: SSH i Accés Remot, arregles justament això: entendràs les tres fases del protocol i què significa de debò l'empremta que et demana acceptar la primera vegada, generaràs claus ed25519, desterraràs l'autenticació per contrasenya, enfortiràs sshd_config directiva a directiva sense quedar-te fora de la màquina, muntaràs túnels per arribar a la base de dades de Tramontana sense exposar-la, i llegiràs amb lastb qui porta 47 intents trucant a la teva porta.