Has portat paper? Ho dèiem seriosament al final de la sessió anterior: aquesta és la sessió més llarga i calculística del mòdul, el múscul més matemàtic del curs. Aquí s'entrena tot el mòdul 5 d'una tirada: conversions binàries, classificació d'adreces d'un cop d'ull, el mètode de 5 passos, subnetting, un disseny VLSM complet de cap a cap — el de la Clínica Azahar, que per fi tindrà pla d'adreçament propi —, lectura de taules NAT i IPv6. La regla de la casa: tot es calcula a mà, amb la taula de pesos i el truc del 256; la calculadora només es permet per verificar. Al món real existeixen calculadores de subxarxes, sí — però qui no sap fer els comptes tampoc no sap detectar quan la calculadora (o el company, o la documentació heretada) es va equivocar.

1. Escalfament: conversions i màscares
2. Classificació d'adreces
3. El mètode de 5 passos
4. Subnetting: quan la longitud fixa no dona
5. Disseny VLSM complet: la Clínica Azahar
6. NAT: llegir la taula i raonar què veu l'exterior
7. IPv6: llegir, abreujar i classificar

• Resol abans de mirar la solució, que és just a sota de cada enunciat. En aquesta sessió més que en cap altra: llegir un càlcul fet produeix una falsa sensació de saber calcular.
• Escriu tots els passos. L'objectiu no és encertar el número: és que el teu procediment sigui tan sistemàtic que hi puguis confiar a les 3 de la matinada d'una migració.
• Verifica en binari quan dubtis. El truc del salt resol el 95 % dels casos; l'AND bit a bit és el jutge d'apel·lació.
• 📌 indica quina lliçó del mòdul 5 repassar si falles. La dificultat creix per apartats: no saltis al VLSM sense haver suat el mètode de 5 passos.

1. Converteix a binari, octet a octet i amb el mètode de restes successives, l'adreça 203.0.113.194 (la IP pública que l'ISP acaba d'assignar al router de la Clínica Azahar a Alacant — ens acompanyarà tota la sessió).
2. Converteix a decimal amb punts, sumant pesos, l'adreça 10101100.00010100.00101000.00001010. Guarda el resultat: el tornaràs a veure.

📌 Repassa si falles: lliçó 05-01.

1. Amb la taula de pesos 128-64-32-16-8-4-2-1:

2. Suma de pesos per octet:

Resultat: 172.20.40.10. És privada (172.20 cau dins de 172.16.0.0/12) i, espòiler, serà l'adreça del servidor d'historials d'Azahar quan dissenyem la seva xarxa a l'exercici 7. Els bons números tornen.

Errors freqüents: a l'octet 194, oblidar que després de restar 128 i 64 en queden 2, i «omplir» amb zeros fins al final sense col·locar el bit del 2. Quan acabis una conversió, suma els pesos dels teus uns i comprova que recuperes el número original — costa 5 segons i caça gairebé tots els despistes.

1. Per a cada candidata, digues si és una màscara vàlida i, si ho és, el seu prefix CIDR: (a) 255.255.248.0 (b) 255.224.255.0 (c) 255.255.255.224 (d) 255.255.191.0.
2. Escriu en decimal amb punts les màscares /30 i /23, i calcula quants hosts útils admet cadascuna.

📌 Repassa si falles: lliçó 05-02.

1. Una màscara vàlida són uns contigus per l'esquerra, zeros contigus per la dreta — sense barreges:
   • (a) Vàlida: 255.255 són 16 uns, i 248 = 11111000 n'afegeix 5 → /21.
   • (b) Invàlida: 255.224.255.0 té zeros (els tres últims bits del 224) seguits d'uns (el 255 del tercer octet). Els uns no són contigus.
   • (c) Vàlida: 24 uns + 224 = 11100000 → /27.
   • (d) Invàlida: 191 = 10111111 — hi ha un zero incrustat entre uns. Cap octet de màscara no pot valer 191; només existeixen 0, 128, 192, 224, 240, 248, 252, 254 i 255.
2. Càlculs:

El /30 amb els seus 2 hosts és el clàssic dels enllaços punt a punt entre routers — el farem servir al pla d'Azahar. El /23 apareix quan un /24 es queda petit i es fusiona amb el veí.

Classifica cada adreça: és pública, privada (RFC 1918) o especial (digues quina)? I és assignable a un equip tal com es presenta? On hi ha màscara, tingues-la en compte.

📌 Repassa si falles: lliçons 05-01 i 05-03.

Errors freqüents: els números 3 i 8 es fallen quan es classifica «de memòria» sense mirar la màscara. .31 i .96 són hosts perfectament vàlids en un /24; són broadcast i xarxa en un /27 i un /28. Cap adreça no és classificable com a xarxa/broadcast/host sense la seva màscara.

El PC d'en Jon té 192.168.20.7 amb el pla nou de Bilbao: màscara /27.

1. Desenvolupa els 5 passos: bits de host, hosts útils, xarxa, broadcast i rang útil. Escriu també la màscara en decimal.
2. Un tècnic despistat configura un portàtil de visita amb 192.168.20.40/27. És a la subxarxa d'en Jon? I ho seria si Bilbao continués en /24?

📌 Repassa si falles: lliçó 05-02.

1. Els 5 passos:

En Jon (.7) és un host vàlid del rang, amb el gateway a .1. Tot quadra amb el dimensionament de la lliçó 05-02.

2. Per a la .40: el múltiple de 32 inferior o igual a 40 és 32 → la seva xarxa és 192.168.20.32/27, no la d'en Jon. No són a la mateixa subxarxa: el portàtil veuria el gateway .1 com a «fora de la seva xarxa» i no funcionaria res. Amb /24 la resposta canvia del tot: tots dos serien a 192.168.20.0/24 i es parlarien directament. Mateixa pregunta, màscara diferent, món diferent.

El proveïdor cloud on Azahar guarda les seves còpies nocturnes fa servir internament l'adreça 10.20.147.200/22 per al servidor de còpies. Desenvolupa els 5 passos complets i verifica l'adreça de xarxa amb l'AND en binari.

📌 Repassa si falles: lliçó 05-02.

Fixa't que 10.20.147.255 no és el broadcast d'«una classe C 10.20.147»: és un host més… no, espera: en aquest /22 sí que és el broadcast, però 10.20.145.255 i 10.20.146.255, que semblen broadcasts, són hosts vàlids i assignables del bloc 144–147. Aquesta és la trampa mental de les màscares que creuen octets: els .255 intermedis són adreces normals.

Errors freqüents: aplicar el salt al quart octet per inèrcia. El salt s'aplica a l'octet interessant — aquell on la màscara no és ni 255 ni 0 —, i la resta d'octets a la seva dreta va a 0 (xarxa) o a 255 (broadcast).

La Clínica Azahar per fi renumera la seva xarxa. Meridiano (que els porta la informàtica) reserva el bloc 172.20.40.0/24 i recull les necessitats — gateway inclòs a cada recompte:

Un tècnic proposa «partir-ho fàcil: totes les subxarxes iguals». Demostra amb números que el subnetting de longitud fixa no pot satisfer aquest encàrrec dins del /24: prova amb el prefix que dona prou subxarxes i amb el que dona prou hosts.

📌 Repassa si falles: lliçó 05-02.

Calen 6 subxarxes i la més gran necessita 37 adreces. Provem les dues vies:

Conclusió: amb longitud fixa, o sobren hosts i falten subxarxes, o a l'inrevés. Les necessitats d'Azahar són desiguals (de 37 adreces a 2), i per a això existeix exactament el VLSM: màscara a mida per a cada subxarxa. Que és l'exercici següent.

Errors freqüents: oblidar comptar el gateway (i respondre que Alacant «només» necessita 36), o resoldre la via A amb 2 bits perquè «6 és a prop de 4». Les potències de 2 no negocien: per a 6 subxarxes en calen 8.

Amb les necessitats de l'exercici 6, dissenya el pla VLSM complet sobre 172.20.40.0/24:

1. Tria el prefix de cada subxarxa.
2. Assigna els blocs en l'ordre correcte i calcula per a cadascun: xarxa, màscara, rang útil, broadcast i gateway (fes servir la primera adreça útil com a gateway; el servidor d'historials ha de quedar a 172.20.40.10).
3. Verifica que cada bloc comença en un múltiple del seu salt i digues quant d'espai queda lliure.

📌 Repassa si falles: lliçó 05-02 (apartat VLSM).

1. Triar prefixos — per a cada necessitat, el bloc més petit el 2^h − 2 del qual la cobreix:

La decisió de Torrevella és la mena de judici que el VLSM et demana: el /29 és matemàticament correcte i operativament asfixiant (la primera tauleta nova obliga a renumerar). Marge raonable > optimització al bit.

2. Assignar de més gran a més petit, cada bloc començant on acaba l'anterior (i en múltiple del seu salt):

Càlcul desenvolupat dels dos primers (la resta segueix el mateix patró):

El servidor d'historials queda a 172.20.40.10, dins del rang estàtic d'Alacant — l'adreça que vas convertir a l'exercici 1.

3. Verificació i espai lliure:

Errors freqüents: assignar els blocs en l'ordre de la llista de requisits en lloc de de més gran a més petit — si el /27 del Wi-Fi es col·loca primer i el /26 després, el /26 hauria de començar a .32, que no és múltiple de 64, i caldria deixar-hi un forat. Gran primer: no és mania, és aritmètica.

Sobre el pla de l'exercici 7, respon raonant:

1. A quina subxarxa pertany 172.20.40.100 i què és (host, xarxa, broadcast)?
2. És assignable 172.20.40.95?
3. Una tauleta de fisio a Alacant (172.20.40.40/26) consulta el servidor d'historials (.10). Lliurament directe o via gateway? I el PC d'Elx 172.20.40.98/28?
4. Un pacient a la sala d'espera (172.20.40.70/27) intenta obrir el servidor d'historials. Què decideix el seu equip, i què hauria de decidir el router d'Alacant?

📌 Repassa si falles: lliçons 05-02 i 05-03.

1. Múltiples de 16 a la zona: 96, 112. El ≤ 100 és 96 → pertany a 172.20.40.96/28 (Elx), rang .97–.110: és un host vàlid d'Elx.
2. No: és el broadcast del bloc Wi-Fi (172.20.40.64/27 → broadcast .95).
3. La tauleta: 40 AND /26 → xarxa .0; el servidor: 10 AND /26 → xarxa .0. Mateixa subxarxa → lliurament directe (ARP + trama, sense router). El PC d'Elx: 98 AND /28 → xarxa .96 ≠ .0 → via gateway .97, i d'allà pel túnel /30 fins a Alacant.
4. L'equip del pacient calcula: 70 AND /27 → xarxa .64; el servidor és a la xarxa .0 → diferent → envia al gateway .65. Fins aquí, capa 3 pura. Però el router d'Alacant ha de tenir una regla que bloquegi sala d'espera → xarxa interna: que el Wi-Fi de pacients sigui la seva pròpia subxarxa existeix precisament per poder aplicar aquesta política. L'adreçament separa; el tallafoc decideix. (Historials mèdics accessibles des del Wi-Fi de la sala d'espera és la mena de titular que cap clínica no vol protagonitzar.)

El router d'Alacant (IP pública 203.0.113.194, la de l'exercici 1) mostra aquesta taula NAT en ple matí:

1. El portal de cites (198.51.100.60) registra als seus logs les connexions rebudes. Quantes adreces d'Azahar veu i quines?
2. Arriba de l'exterior un paquet TCP amb destinació 203.0.113.194:40002. Què en fa el router, pas a pas?
3. Arriba de l'exterior un paquet TCP amb destinació 203.0.113.194:443. Què fa el router i per què?
4. Què està fent, plausiblement, cada equip intern? (Pista: .21 és el PC de recepció, .40 una tauleta, .10 el servidor.)
5. Quan un PC d'Elx consulta el servidor d'historials, apareix una fila en aquesta taula?

📌 Repassa si falles: lliçó 05-03.

1. Una de sola: 203.0.113.194. Les dues primeres files (recepció i tauleta) van al portal, però totes dues surten traduïdes a la mateixa IP pública amb ports diferents (40001 i 40002). Per al portal, «tota la Clínica Azahar» és una adreça — l'essència del PAT.
2. Pas a pas: el router busca el port extern 40002 a la taula → troba la fila de la tauleta → reescriu la destinació 203.0.113.194:40002 → 172.20.40.40:49802 → recalcula checksums → lliura el paquet a la LAN a la tauleta. La traducció es desfà de manera transparent.
3. Busca el 443 com a port extern a la taula: no hi ha fila (ningú de dins no va iniciar aquesta connexió amb aquest port extern) i no existeix cap regla DNAT per al 443. El descarta. És el «pseudotallafoc» del NAT: l'entrant no sol·licitat mor al router.
4. Lectura plausible: recepció (.21) està fent servir el portal de cites per HTTPS i resolent un nom per DNS (la fila UDP:53 contra 192.0.2.53); la tauleta (.40) també és al portal de cites; el servidor (.10) manté una connexió sortint HTTPS amb 198.51.100.25 — per exemple, pujant la còpia o descarregant actualitzacions. Nota fina: que el servidor aparegui com a origen d'una connexió sortint és normal; els servidors també són clients d'altres.
5. No. Elx → historials viatja pel túnel VPN de lloc a lloc amb les adreces privades intactes d'extrem a extrem (172.20.40.98 → 172.20.40.10). El NAT només actua a la frontera amb Internet; el trànsit intern entre seus no es tradueix.

A Meridiano València (IP pública 203.0.113.50), un portàtil infectat del Wi-Fi de convidats llança milers de peticions abusives contra un servei en línia. El servei respon bandejant «la IP de l'atacant». Resultat: al cap de cinc minuts, ningú de València — ni la Marta, ni l'Ana, ni el servidor — no pot fer servir aquell servei.

1. Quina adreça va bandejar el servei i per què afecta tothom?
2. Pot el servei extern distingir el portàtil culpable de la Marta? Pot fer-ho Meridiano? Amb què?
3. Bilbao continua accedint al servei sense problema. Per què?

📌 Repassa si falles: lliçó 05-03.

1. Va bandejar 203.0.113.50 — l'única adreça que veu. Amb PAT, els ~20 equips de València (VLAN corporativa i convidats incloses) comparteixen aquesta IP pública: el bandeig d'«un» és el bandeig de tots. Compartir IP és compartir reputació.
2. El servei extern, no: per a ell totes les connexions arriben de la mateixa adreça (com a molt distingeix ports d'origen, que no identifiquen equips de manera estable). Meridiano, sí: la taula NAT del router (i els seus registres amb marques de temps) mapa cada connexió externa a la IP privada interna que la va crear. És exactament el motiu pel qual es guarden els registres del router: 203.0.113.50:41207 a les 10:32:15 → fila → 192.168.x.x, el culpable.
3. Bilbao surt a Internet pel seu propi router amb la seva pròpia IP pública — una altra frontera NAT diferent. El bandeig de la IP de València no l'abasta. (I de passada: si el trànsit de Bilbao a Internet passés per la VPN i sortís per València, sí que estaria bandejat — la topologia de sortida importa.)

1. Comprimeix a forma canònica: 2001:0db8:00f0:0000:0000:0000:0000:0a2f
2. Comprimeix a forma canònica (compte, dues tires de zeros): 2001:0db8:0000:0000:00aa:0000:0000:0001
3. Expandeix als 8 grups: 2001:db8:5a00:113::1:20
4. És vàlida 2001:db8::40::7? Per què?

📌 Repassa si falles: lliçó 05-04.

4. Invàlida: conté dos ::. Seria ambigua — quants grups amaga cadascun? Amb 8 grups totals i 4 de visibles en queden 4 d'ocults, però es podrien repartir 1+3, 2+2 o 3+1: tres adreces diferents. Per això la norma només permet un ::.

Classifica cada adreça (tipus i àmbit) i dona'n l'«equivalent mental» en IPv4:

1. fe80::be24:11ff:fe9a:3c01
2. ::1
3. 2001:db8:5a00:10:d4a1:8c2e:90bb:41f7
4. fd12:3456:789a::10
5. ff02::2
6. ::

📌 Repassa si falles: lliçó 05-04.

El matís que separa qui ha entès IPv6: veure una fe80:: en un ip addr no és cap problema (al contrari que una 169.254.x.x, que sempre ho és). I buscar «l'adreça de broadcast» d'una subxarxa IPv6 és buscar una cosa que no existeix.

L'ISP delega a Azahar el prefix 2001:db8:5a00::/56.

1. Quantes subxarxes /64 caben en aquest /56?
2. Proposa un /64 per a cada subxarxa del pla de l'exercici 7 (Alacant cablejada, sala d'espera, Elx, Torrevella), triant grups de subxarxa llegibles.
3. Cal dimensionar quants hosts caben a cadascuna? I els dos túnels /30 — necessiten un bloc «petit»?

📌 Repassa si falles: lliçó 05-04.

1. Bits de subxarxa: 64 − 56 = 8 → 2⁸ = 256 subxarxes /64. (El /48 de Meridiano en donava 65.536; un /56, típic de pime, en dona 256 — de sobres per a 3 seus.)
2. Amb el /56, l'octet final del quart grup és el que s'enumera:

El pla sencer s'escriu en quatre línies, sense salts, sense 2^h − 2, sense broadcast. Compara-ho amb la suor de l'exercici 7: aquesta diferència és IPv6. 3. No: cada /64 té 2⁶⁴ adreces — la pregunta «quants hosts hi caben?» perd el sentit. I els túnels també poden ser /64 (p. ex. 2001:db8:5a00:f1::/64 i :f2::/64): no hi ha cap escassetat que justifiqui el vestit a mida del /30. En IPv6 es compten subxarxes, no hosts.

Recapitulació de les ensopegades que més s'han repetit (si has caigut en unes quantes, és normal; si continues caient-hi la setmana que ve, repassa):

• Classificar sense màscara. Xarxa, broadcast o host és un veredicte de la parella adreça+màscara (exercicis 3, 4, 8). Demanar la màscara és l'acte reflex número u del professional.
• Oblidar el −2 i el gateway en dimensionar (exercicis 6 i 7): 2^h combinacions, 2^h − 2 hosts, i una d'elles se l'endú el router.
• VLSM en ordre d'arribada en lloc de gran→petit: produeix blocs desalineats i forats (exercici 7).
• «Comença per 172, és privada»: només de 172.16 a 172.31 (exercici 3). El segon octet decideix.
• Expandir IPv6 omplint per la dreta: 113 és 0113, no 1130 (exercici 11). Els zeros restaurats van al davant.
• Consell: verifica cada pla sumant mides de bloc (≤ 256 en un /24?) i comprovant que cada xarxa és múltiple del seu salt. Dues comprovacions, trenta segons, zero encavalcaments.
• Consell: guarda la teva solució de l'exercici 7. El pla d'Azahar que acabes de dissenyar és, literalment, l'escenari sobre el qual es trencaran coses a la pròxima lliçó.

Sessió de peses completada — la més dura del gimnàs. Has convertit binari en decimal i tornada sense calculadora, classificat adreces amb trampa i sense, executat el mètode de 5 passos amb la frontera a qualsevol octet, demostrat amb números per què la longitud fixa no li serveix a Azahar i dissenyat el seu pla VLSM complet (que ara és el teu pla), llegit una taula NAT com la llegeix el router i raonat què veu — i què no pot veure — l'exterior, i tancat amb IPv6: comprimir, expandir, classificar i planificar en quatre línies el que en IPv4 va costar una pàgina de comptes.

Queda l'última sessió del curs, i és diferent de totes: a Casos Pràctics ja no hi ha apartats per tema ni pistes de quina lliçó repassar. Hi haurà símptomes, sortides d'ordres i usuaris esperant — com a la vida real —, i hauràs de creuar tot el curs d'una vegada: el mètode del mòdul 6, l'adreçament d'avui, els protocols, les capes. Els escenaris et sonaran: Meridiano… i la xarxa d'Azahar que acabes de dissenyar. Res no espatlla tant un bon pla d'adreçament com posar-lo en producció.