¿Has traído papel? Lo decíamos en serio al final de la sesión anterior: esta es la sesión más larga y calculística del módulo, el músculo más matemático del curso. Aquí se entrena todo el módulo 5 de una tacada: conversiones binarias, clasificación de direcciones a golpe de vista, el método de 5 pasos, subnetting, un diseño VLSM completo de principio a fin — el de la Clínica Azahar, que por fin va a tener plan de direccionamiento propio —, lectura de tablas NAT e IPv6. La regla de la casa: todo se calcula a mano, con la tabla de pesos y el truco del 256; la calculadora solo se permite para verificar. En el mundo real existen calculadoras de subredes, sí — pero quien no sabe hacer las cuentas tampoco sabe detectar cuándo la calculadora (o el compañero, o la documentación heredada) se equivocó.

1. Calentamiento: conversiones y máscaras
2. Clasificación de direcciones
3. El método de 5 pasos
4. Subnetting: cuando la longitud fija no da
5. Diseño VLSM completo: la Clínica Azahar
6. NAT: leer la tabla y razonar qué ve el exterior
7. IPv6: leer, abreviar y clasificar

• Resuelve antes de mirar la solución, que está justo debajo de cada enunciado. En esta sesión más que en ninguna: leer un cálculo hecho produce una falsa sensación de saber calcular.
• Escribe todos los pasos. El objetivo no es acertar el número: es que tu procedimiento sea tan sistemático que puedas confiar en él a las 3 de la madrugada de una migración.
• Verifica en binario cuando dudes. El truco del salto resuelve el 95 % de los casos; el AND bit a bit es el juez de apelación.
• 📌 indica qué lección del módulo 5 repasar si fallas. La dificultad crece por apartados: no saltes al VLSM sin haber sudado el método de 5 pasos.

1. Convierte a binario, octeto a octeto y con el método de restas sucesivas, la dirección 203.0.113.194 (la IP pública que el ISP acaba de asignar al router de la Clínica Azahar en Alicante — nos acompañará toda la sesión).
2. Convierte a decimal punteado, sumando pesos, la dirección 10101100.00010100.00101000.00001010. Guarda el resultado: lo vas a volver a ver.

📌 Repasa si fallas: lección 05-01.

1. Con la tabla de pesos 128-64-32-16-8-4-2-1:

2. Suma de pesos por octeto:

Resultado: 172.20.40.10. Es privada (172.20 cae dentro de 172.16.0.0/12) y, spoiler, será la dirección del servidor de historiales de Azahar cuando diseñemos su red en el ejercicio 7. Los buenos números vuelven.

Errores frecuentes: en el octeto 194, olvidar que tras restar 128 y 64 quedan 2, y "rellenar" con ceros hasta el final sin colocar el bit del 2. Cuando termines una conversión, suma los pesos de tus unos y comprueba que recuperas el número original — cuesta 5 segundos y caza casi todos los despistes.

1. Para cada candidata, di si es una máscara válida y, si lo es, su prefijo CIDR: (a) 255.255.248.0 (b) 255.224.255.0 (c) 255.255.255.224 (d) 255.255.191.0.
2. Escribe en decimal punteado las máscaras /30 y /23, y calcula cuántos hosts útiles admite cada una.

📌 Repasa si fallas: lección 05-02.

1. Una máscara válida son unos contiguos por la izquierda, ceros contiguos por la derecha — sin mezclas:
   • (a) Válida: 255.255 son 16 unos, y 248 = 11111000 añade 5 → /21.
   • (b) Inválida: 255.224.255.0 tiene ceros (los tres últimos bits del 224) seguidos de unos (el 255 del tercer octeto). Los unos no son contiguos.
   • (c) Válida: 24 unos + 224 = 11100000 → /27.
   • (d) Inválida: 191 = 10111111 — hay un cero incrustado entre unos. Ningún octeto de máscara puede valer 191; solo existen 0, 128, 192, 224, 240, 248, 252, 254 y 255.
2. Cálculos:

El /30 con sus 2 hosts es el clásico de los enlaces punto a punto entre routers — lo usaremos en el plan de Azahar. El /23 aparece cuando un /24 se queda pequeño y se fusiona con el vecino.

Clasifica cada dirección: ¿es pública, privada (RFC 1918) o especial (di cuál)? ¿Y es asignable a un equipo tal como se presenta? Donde hay máscara, tenla en cuenta.

📌 Repasa si fallas: lecciones 05-01 y 05-03.

Errores frecuentes: los números 3 y 8 se fallan cuando se clasifica "de memoria" sin mirar la máscara. .31 y .96 son hosts perfectamente válidos en un /24; son broadcast y red en un /27 y un /28. Ninguna dirección es clasificable como red/broadcast/host sin su máscara.

El PC de Jon tiene 192.168.20.7 con el plan nuevo de Bilbao: máscara /27.

1. Desarrolla los 5 pasos: bits de host, hosts útiles, red, broadcast y rango útil. Escribe también la máscara en decimal.
2. Un técnico despistado configura un portátil de visita con 192.168.20.40/27. ¿Está en la subred de Jon? ¿Y lo estaría si Bilbao siguiera en /24?

📌 Repasa si fallas: lección 05-02.

1. Los 5 pasos:

Jon (.7) es un host válido del rango, con el gateway en .1. Todo cuadra con el dimensionamiento de la lección 05-02.

2. Para .40: el múltiplo de 32 inferior o igual a 40 es 32 → su red es 192.168.20.32/27, no la de Jon. No están en la misma subred: el portátil vería el gateway .1 como "fuera de su red" y no funcionaría nada. Con /24 la respuesta cambia por completo: ambos estarían en 192.168.20.0/24 y se hablarían directamente. Misma pregunta, distinta máscara, distinto mundo.

El proveedor cloud donde Azahar guarda sus copias nocturnas usa internamente la dirección 10.20.147.200/22 para el servidor de copias. Desarrolla los 5 pasos completos y verifica la dirección de red con el AND en binario.

📌 Repasa si fallas: lección 05-02.

Fíjate en que 10.20.147.255 no es el broadcast de "una clase C 10.20.147": es un host más… no, espera: en este /22 sí es el broadcast, pero 10.20.145.255 y 10.20.146.255, que parecen broadcasts, son hosts válidos y asignables del bloque 144–147. Esa es la trampa mental de las máscaras que cruzan octetos: los .255 intermedios son direcciones normales.

Errores frecuentes: aplicar el salto en el cuarto octeto por inercia. El salto se aplica en el octeto interesante — aquel donde la máscara no es ni 255 ni 0 —, y el resto de octetos a su derecha va a 0 (red) o a 255 (broadcast).

La Clínica Azahar por fin renumera su red. Meridiano (que les lleva la informática) reserva el bloque 172.20.40.0/24 y recopila las necesidades — gateway incluido en cada recuento:

Un técnico propone "partirlo fácil: todas las subredes iguales". Demuestra con números que el subnetting de longitud fija no puede satisfacer este encargo dentro del /24: prueba con el prefijo que da suficientes subredes y con el que da suficientes hosts.

📌 Repasa si fallas: lección 05-02.

Hacen falta 6 subredes y la mayor necesita 37 direcciones. Probemos las dos vías:

Conclusión: con longitud fija, o sobran hosts y faltan subredes, o al revés. Las necesidades de Azahar son desiguales (de 37 direcciones a 2), y para eso existe exactamente VLSM: máscara a medida para cada subred. Que es el siguiente ejercicio.

Errores frecuentes: olvidar contar el gateway (y responder que Alicante "solo" necesita 36), o resolver la vía A con 2 bits porque "6 está cerca de 4". Las potencias de 2 no negocian: para 6 subredes hacen falta 8.

Con las necesidades del ejercicio 6, diseña el plan VLSM completo sobre 172.20.40.0/24:

1. Elige el prefijo de cada subred.
2. Asigna los bloques en el orden correcto y calcula para cada uno: red, máscara, rango útil, broadcast y gateway (usa la primera dirección útil como gateway; el servidor de historiales debe quedar en 172.20.40.10).
3. Verifica que cada bloque empieza en un múltiplo de su salto y di cuánto espacio queda libre.

📌 Repasa si fallas: lección 05-02 (apartado VLSM).

1. Elegir prefijos — para cada necesidad, el menor bloque cuyo 2^h − 2 la cubre:

La decisión de Torrevieja es la clase de juicio que VLSM te pide: el /29 es matemáticamente correcto y operativamente asfixiante (la primera tablet nueva obliga a renumerar). Margen razonable > optimización al bit.

2. Asignar de mayor a menor, cada bloque empezando donde acaba el anterior (y en múltiplo de su salto):

Cálculo desarrollado de los dos primeros (los demás siguen el mismo patrón):

El servidor de historiales queda en 172.20.40.10, dentro del rango estático de Alicante — la dirección que convertiste en el ejercicio 1.

3. Verificación y espacio libre:

Errores frecuentes: asignar los bloques en el orden de la lista de requisitos en vez de de mayor a menor — si el /27 de la Wi-Fi se coloca primero y el /26 después, el /26 tendría que empezar en .32, que no es múltiplo de 64, y habría que dejar un agujero. Grande primero: no es manía, es aritmética.

Sobre el plan del ejercicio 7, responde razonando:

1. ¿A qué subred pertenece 172.20.40.100 y qué es (host, red, broadcast)?
2. ¿Es asignable 172.20.40.95?
3. Una tablet de fisio en Alicante (172.20.40.40/26) consulta el servidor de historiales (.10). ¿Entrega directa o vía gateway? ¿Y el PC de Elche 172.20.40.98/28?
4. Un paciente en la sala de espera (172.20.40.70/27) intenta abrir el servidor de historiales. ¿Qué decide su equipo, y qué debería decidir el router de Alicante?

📌 Repasa si fallas: lecciones 05-02 y 05-03.

1. Múltiplos de 16 en la zona: 96, 112. El ≤ 100 es 96 → pertenece a 172.20.40.96/28 (Elche), rango .97–.110: es un host válido de Elche.
2. No: es el broadcast del bloque Wi-Fi (172.20.40.64/27 → broadcast .95).
3. La tablet: 40 AND /26 → red .0; el servidor: 10 AND /26 → red .0. Misma subred → entrega directa (ARP + trama, sin router). El PC de Elche: 98 AND /28 → red .96 ≠ .0 → vía gateway .97, y de ahí por el túnel /30 hasta Alicante.
4. El equipo del paciente calcula: 70 AND /27 → red .64; el servidor está en la red .0 → distinto → envía al gateway .65. Hasta aquí, capa 3 pura. Pero el router de Alicante debe tener una regla que bloquee sala de espera → red interna: que la Wi-Fi de pacientes sea su propia subred existe precisamente para poder aplicar esa política. El direccionamiento separa; el firewall decide. (Historiales médicos accesibles desde la Wi-Fi de la sala de espera es el tipo de titular que ninguna clínica quiere protagonizar.)

El router de Alicante (IP pública 203.0.113.194, la del ejercicio 1) muestra esta tabla NAT en plena mañana:

1. El portal de citas (198.51.100.60) registra en sus logs las conexiones recibidas. ¿Cuántas direcciones de Azahar ve y cuáles?
2. Llega del exterior un paquete TCP con destino 203.0.113.194:40002. ¿Qué hace el router con él, paso a paso?
3. Llega del exterior un paquete TCP con destino 203.0.113.194:443. ¿Qué hace el router y por qué?
4. ¿Qué está haciendo, plausiblemente, cada equipo interno? (Pista: .21 es el PC de recepción, .40 una tablet, .10 el servidor.)
5. Cuando un PC de Elche consulta el servidor de historiales, ¿aparece una fila en esta tabla?

📌 Repasa si fallas: lección 05-03.

1. Una sola: 203.0.113.194. Las dos primeras filas (recepción y tablet) van al portal, pero ambas salen traducidas a la misma IP pública con puertos distintos (40001 y 40002). Para el portal, "toda la Clínica Azahar" es una dirección — la esencia de PAT.
2. Paso a paso: el router busca el puerto externo 40002 en la tabla → encuentra la fila de la tablet → reescribe el destino 203.0.113.194:40002 → 172.20.40.40:49802 → recalcula checksums → entrega el paquete en la LAN a la tablet. La traducción se deshace de forma transparente.
3. Busca 443 como puerto externo en la tabla: no hay fila (nadie de dentro inició esa conexión con ese puerto externo) y no existe regla DNAT para el 443. Lo descarta. Es el "pseudo-firewall" de NAT: lo entrante no solicitado muere en el router.
4. Lectura plausible: recepción (.21) está usando el portal de citas por HTTPS y resolviendo un nombre por DNS (la fila UDP:53 contra 192.0.2.53); la tablet (.40) también está en el portal de citas; el servidor (.10) mantiene una conexión saliente HTTPS con 198.51.100.25 — por ejemplo, subiendo la copia o descargando actualizaciones. Nota fina: que el servidor aparezca como origen de una conexión saliente es normal; los servidores también son clientes de otros.
5. No. Elche → historiales viaja por el túnel VPN sitio a sitio con las direcciones privadas intactas de extremo a extremo (172.20.40.98 → 172.20.40.10). NAT solo actúa en la frontera con Internet; el tráfico interno entre sedes no se traduce.

En Meridiano Valencia (IP pública 203.0.113.50), un portátil infectado de la Wi-Fi de invitados lanza miles de peticiones abusivas contra un servicio online. El servicio responde baneando "la IP del atacante". Resultado: a los cinco minutos, nadie en Valencia — ni Marta, ni Ana, ni el servidor — puede usar ese servicio.

1. ¿Qué dirección baneó el servicio y por qué afecta a todos?
2. ¿Puede el servicio externo distinguir al portátil culpable de Marta? ¿Puede hacerlo Meridiano? ¿Con qué?
3. Bilbao sigue accediendo al servicio sin problema. ¿Por qué?

📌 Repasa si fallas: lección 05-03.

1. Baneó 203.0.113.50 — la única dirección que ve. Con PAT, los ~20 equipos de Valencia (VLAN corporativa e invitados incluidas) comparten esa IP pública: el baneo de "uno" es el baneo de todos. Compartir IP es compartir reputación.
2. El servicio externo, no: para él todas las conexiones llegan de la misma dirección (como mucho distingue puertos de origen, que no identifican equipos de forma estable). Meridiano, sí: la tabla NAT del router (y sus registros con marcas de tiempo) mapea cada conexión externa a la IP privada interna que la creó. Es exactamente el motivo por el que los registros del router se guardan: 203.0.113.50:41207 a las 10:32:15 → fila → 192.168.x.x, el culpable.
3. Bilbao sale a Internet por su propio router con su propia IP pública — otra frontera NAT distinta. El baneo de la IP de Valencia no le alcanza. (Y de paso: si el tráfico de Bilbao a Internet pasara por la VPN y saliera por Valencia, sí estaría baneado — la topología de salida importa.)

1. Comprime a forma canónica: 2001:0db8:00f0:0000:0000:0000:0000:0a2f
2. Comprime a forma canónica (ojo, dos tiras de ceros): 2001:0db8:0000:0000:00aa:0000:0000:0001
3. Expande a los 8 grupos: 2001:db8:5a00:113::1:20
4. ¿Es válida 2001:db8::40::7? ¿Por qué?

📌 Repasa si fallas: lección 05-04.

4. Inválida: contiene dos ::. Sería ambigua — ¿cuántos grupos esconde cada uno? Con 8 grupos totales y 4 visibles quedan 4 ocultos, pero podrían repartirse 1+3, 2+2 o 3+1: tres direcciones distintas. Por eso la norma solo permite un ::.

Clasifica cada dirección (tipo y ámbito) y da su "equivalente 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. ::

📌 Repasa si fallas: lección 05-04.

El matiz que separa al que ha entendido IPv6: ver una fe80:: en un ip addr no es un problema (al contrario que una 169.254.x.x, que siempre lo es). Y buscar "la dirección de broadcast" de una subred IPv6 es buscar algo que no existe.

El ISP delega a Azahar el prefijo 2001:db8:5a00::/56.

1. ¿Cuántas subredes /64 caben en ese /56?
2. Propón un /64 para cada subred del plan del ejercicio 7 (Alicante cableada, sala de espera, Elche, Torrevieja), eligiendo grupos de subred legibles.
3. ¿Hay que dimensionar cuántos hosts caben en cada una? ¿Y los dos túneles /30 — necesitan un bloque "pequeño"?

📌 Repasa si fallas: lección 05-04.

1. Bits de subred: 64 − 56 = 8 → 2⁸ = 256 subredes /64. (El /48 de Meridiano daba 65.536; un /56, típico de pyme, da 256 — de sobra para 3 sedes.)
2. Con el /56, el octeto final del cuarto grupo es el que se enumera:

El plan entero se escribe en cuatro líneas, sin saltos, sin 2^h − 2, sin broadcast. Compáralo con el sudor del ejercicio 7: esa diferencia es IPv6. 3. No: cada /64 tiene 2⁶⁴ direcciones — la pregunta "¿cuántos hosts caben?" pierde el sentido. Y los túneles pueden ser /64 también (p. ej. 2001:db8:5a00:f1::/64 y :f2::/64): no hay escasez que justifique el traje a medida del /30. En IPv6 se cuentan subredes, no hosts.

Recapitulación de los tropiezos que más se han repetido (si has caído en varios, es normal; si sigues cayendo la semana que viene, repasa):

• Clasificar sin máscara. Red, broadcast u host es un veredicto de la pareja dirección+máscara (ejercicios 3, 4, 8). Pedir la máscara es el acto reflejo número uno del profesional.
• Olvidar el −2 y el gateway al dimensionar (ejercicios 6 y 7): 2^h combinaciones, 2^h − 2 hosts, y una de ellas se la lleva el router.
• VLSM en orden de llegada en vez de mayor→menor: produce bloques desalineados y agujeros (ejercicio 7).
• "Empieza por 172, es privada": solo de 172.16 a 172.31 (ejercicio 3). El segundo octeto decide.
• Expandir IPv6 rellenando por la derecha: 113 es 0113, no 1130 (ejercicio 11). Los ceros restaurados van delante.
• Consejo: verifica cada plan sumando tamaños de bloque (¿≤ 256 en un /24?) y comprobando que cada red es múltiplo de su salto. Dos comprobaciones, treinta segundos, cero solapes.
• Consejo: guarda tu solución del ejercicio 7. El plan de Azahar que acabas de diseñar es, literalmente, el escenario sobre el que se romperán cosas en la próxima lección.

Sesión de pesas completada — la más dura del gimnasio. Has convertido binario en decimal y vuelta sin calculadora, clasificado direcciones con y sin trampa, ejecutado el método de 5 pasos con la frontera en cualquier octeto, demostrado con números por qué la longitud fija no le vale a Azahar y diseñado su plan VLSM completo (que ahora es tu plan), leído una tabla NAT como la lee el router y razonado qué ve — y qué no puede ver — el exterior, y cerrado con IPv6: comprimir, expandir, clasificar y planificar en cuatro líneas lo que en IPv4 costó una página de cuentas.

Queda la última sesión del curso, y es distinta a todas: en Casos Prácticos ya no hay apartados por tema ni pistas de qué lección repasar. Habrá síntomas, salidas de comandos y usuarios esperando — como en la vida real —, y tendrás que cruzar todo el curso de una vez: el método del módulo 6, el direccionamiento de hoy, los protocolos, las capas. Los escenarios te sonarán: Meridiano… y la red de Azahar que acabas de diseñar. Nada estropea tanto un buen plan de direccionamiento como ponerlo en producción.