Cuestión 1 — Direccionamiento VLSM partiendo de 172.16.0.0/16

Paso 1. Ordenar de mayor a menor y calcular bits de host (2^n − 2 ≥ hosts):

Nota clave: 60 hosts NO caben en una /26 (62 útiles caben, sí), pero por holgura/escalabilidad el diseño «más ajustado» para 60 es /26 (62 útiles). Sin embargo, para dejar margen real de crecimiento del aula principal y respetar la asignación de mayor a menor sin colisiones, se asigna a Aula 1 una /25 (126 útiles) como bloque de cabecera. Si se exige el ajuste estricto mínimo, Aula 1 = /26 (62 útiles). A continuación se documenta el diseño con el ajuste estricto (la opción de máxima eficiencia), que es el que pide el enunciado («subred más ajustada»):

Diseño ajustado (eficiencia máxima):

Atención: 30 equipos requieren 30 útiles; una /27 da solo 30 útiles (2^5−2 = 30), que es JUSTO. Si se desea margen, /26. Para el ajuste estricto, /27 vale exactamente. La DMZ con 10 hosts → /28 (14 útiles).

Paso 2. Asignación contigua sobre 172.16.0.0/16 (mayor a menor):

Figura 1. Mapa de direccionamiento VLSM sobre 172.16.0.0/24 (anchos proporcionales al tamaño de cada subred).

La regla de tamaño de cada subred es \text{hosts útiles} = 2^{n} - 2, con n el número de bits de host.

Justificación del orden: En VLSM se asignan los bloques de mayor tamaño primero porque deben alinearse a fronteras de subred «potencia de 2»; hacerlo de menor a mayor produciría solapamientos o desperdicio (un bloque grande no podría empezar en una frontera ya ocupada por uno pequeño). Asignando de mayor a menor, cada subred encaja exactamente tras la anterior sin huecos internos.

Puertas de enlace recomendadas (primera IP útil de cada subred):

• Aula 1: 172.16.0.1 · Departamentos: 172.16.0.65 · Aula 2: 172.16.0.129 · DMZ: 172.16.0.161

Espacio libre para futuros segmentos: Tras la DMZ, el siguiente bloque libre comienza en 172.16.0.176 y se extiende hasta 172.16.255.255. Es decir, queda libre prácticamente todo el espacio desde 172.16.0.176/28 en adelante: un rango enorme (más de 65.000 direcciones) disponible para nuevas VLAN (biblioteca, WiFi de invitados, IoT, telefonía IP, etc.). Conviene documentar el siguiente bloque alineado libre como 172.16.1.0/24 reservado para crecimiento limpio.

Cuestión 2 — Enrutamiento y NAT

(a) Reenvío de puertos (PAT/Port Forwarding) para publicar el servidor web por HTTPS:

La IP pública del centro es la interfaz externa de R1: 80.58.10.65. El servidor web interno está en la DMZ; supongamos 172.16.0.162. Se necesita una traducción DNAT del puerto 443 entrante:

! Cisco IOS
ip nat inside source static tcp 172.16.0.162 443 80.58.10.65 443 extendable

# iptables (router Linux R1; ifaz externa eth0)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
         -j DNAT --to-destination 172.16.0.162:443
iptables -A FORWARD -p tcp -d 172.16.0.162 --dport 443 -m state \
         --state NEW,ESTABLISHED,RELATED -j ACCEPT

Así, una petición a https://80.58.10.65 se reescribe hacia el servidor interno manteniendo el puerto 443.

Figura 2. Reenvío de puertos (DNAT): publica el servidor interno por HTTPS a través de la IP pública.

(b) Por qué un /29 ofrece solo 6 direcciones utilizables:

Un prefijo /29 deja 32 − 29 = 3 bits de host, luego hay 2^3 = 8 direcciones totales. De esas 8 se descuentan 2 no asignables a hosts: la dirección de red (todos los bits de host a 0) y la dirección de broadcast (todos a 1). Resultado: 8 − 2 = 6 direcciones utilizables. En el bloque 80.58.10.64/29: red = 80.58.10.64, broadcast = 80.58.10.71, y utilizables 80.58.10.65–80.58.10.70 (la .65 es la interfaz externa de R1).

Formalmente, un /29 ofrece 2^{3} - 2 = 6 direcciones utilizables.

(c) NAT estático vs PAT (overload) y elección para los ~150 equipos:

• NAT estático: correspondencia 1:1 permanente entre una IP privada y una IP pública. Requiere tantas IP públicas como hosts a traducir. Se usa para publicar servidores (acceso entrante predecible).
• PAT / NAT de sobrecarga (overload): correspondencia N:1. Muchas IP privadas comparten una sola IP pública distinguiéndose por el número de puerto de origen (la tabla de traducción guarda IP:puerto interno ↔ IP pública:puerto). Solo permite conexiones iniciadas desde dentro.

Para que ~150 equipos naveguen con una única IP pública la única solución viable es PAT (overload): el NAT estático exigiría 150 IP públicas (imposible con un /29). Configuración:

! Cisco IOS
access-list 1 permit 172.16.0.0 0.0.255.255
ip nat inside source list 1 interface GigabitEthernet0/0 overload

# iptables
iptables -t nat -A POSTROUTING -s 172.16.0.0/16 -o eth0 -j MASQUERADE

Figura 3. PAT (overload): los ~150 equipos comparten la única IP pública multiplexando por puerto de origen.

Cuestión 3 — Seguridad (ACL). Versión iptables (router/firewall Linux R1)

Interfaces de R1 (subinterfaces VLAN): Aula1 eth1.10, Departamentos eth1.20, Aula2 eth1.30, Servidores/DMZ eth1.40, externa eth0. Servidor: 172.16.0.162.

Figura 4. Matriz de alcance resultante de la ACL (origen → destino).

# Política por defecto restrictiva
iptables -P FORWARD DROP

# Permitir tráfico de respuesta de conexiones ya establecidas
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# (R1) HTTP/HTTPS + ICMP echo desde CUALQUIER segmento HACIA el servidor
iptables -A FORWARD -d 172.16.0.162 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A FORWARD -d 172.16.0.162 -p icmp --icmp-type echo-request -j ACCEPT

# Departamentos: salida COMPLETA a Internet
iptables -A FORWARD -s 172.16.0.64/26 -o eth0 -j ACCEPT

# Aula 2 -> Servidores SOLO 80 y 443 (las reglas anteriores ya permiten 80/443
# al servidor); ahora se BLOQUEA cualquier otro acceso de Aula2 a la DMZ:
iptables -A FORWARD -s 172.16.0.128/27 -d 172.16.0.160/28 -j DROP

# (deny implícito final por política DROP)

Notas de aplicación: las reglas se aplican en la cadena FORWARD (tráfico que atraviesa R1). El orden es esencial: las reglas que permiten 80/443/icmp al servidor van antes del DROP de Aula2→DMZ, de modo que Aula2 sí alcanza la DMZ por 80/443 pero el resto de puertos queda bloqueado por el DROP.

Equivalente Cisco IOS (ACL extendida, aplicada in en cada subinterfaz de entrada):

ip access-list extended ACL-SERVIDOR
 permit tcp any host 172.16.0.162 eq 80
 permit tcp any host 172.16.0.162 eq 443
 permit icmp any host 172.16.0.162 echo
!
ip access-list extended ACL-AULA2
 permit tcp 172.16.0.128 0.0.0.31 host 172.16.0.162 eq 80
 permit tcp 172.16.0.128 0.0.0.31 host 172.16.0.162 eq 443
 deny   ip  172.16.0.128 0.0.0.31 172.16.0.160 0.0.0.15
 permit ip  any any
!
interface Gi0/0.30
 ip access-group ACL-AULA2 in

(La ACL de Aula2 se aplica in en la subinterfaz de la VLAN 30; recuerda el deny ip any any implícito y el permit ip any any final para no cortar el resto de tráfico legítimo de Aula2 hacia Internet.)

Cuestión 4 — Buscar el error (DHCP isc-dhcp-server, Aula 1)

Configuración original:

subnet 172.16.0.0 netmask 255.255.255.192 {
    range 172.16.0.10 172.16.0.250;
    option routers 172.16.1.1;
    option domain-name-servers 8.8.8.8;
}

Errores detectados (coherencia con el diseño de la C1, Aula 1 = 172.16.0.0/26):

1. Rango fuera de la subred. La máscara /26 (255.255.255.192) limita la subred a 172.16.0.0–172.16.0.63. El range llega hasta 172.16.0.250, fuera del rango válido (y solaparía con Departamentos y Aula 2). El servidor no puede ofertar direcciones inexistentes en esa subred.
2. Gateway incorrecta. option routers 172.16.1.1 no pertenece a la subred 172.16.0.0/26; la puerta de enlace de Aula 1 es 172.16.0.1. Por eso «no hay conectividad entre VLAN»: los equipos reciben una gateway inalcanzable.
3. DNS sin servidor interno. domain-name-servers 8.8.8.8 (DNS público de Google) no resuelve el dominio interno del centro. Debe apuntarse al DNS interno Lliurex (172.16.0.162). Por eso «no resuelven el dominio interno».
4. (Complementario) Falta declarar option domain-name para el sufijo local del centro.

Figura 5. Los tres errores de la configuración DHCP y su corrección.

Configuración corregida y coherente:

subnet 172.16.0.0 netmask 255.255.255.192 {
    range 172.16.0.10 172.16.0.60;
    option routers 172.16.0.1;
    option subnet-mask 255.255.255.192;
    option domain-name "ies-serracalderona.local";
    option domain-name-servers 172.16.0.162, 8.8.8.8;
    default-lease-time 3600;
    max-lease-time 7200;
}

Justificación: el range queda dentro de 172.16.0.1–172.16.0.62 (se reserva .1 para la gateway y se deja margen para servidores con IP fija); la gateway es la real de la subred; el DNS primario es el interno (resuelve el dominio local y delega lo externo por forwarders), con 8.8.8.8 como secundario de respaldo.

Cuestión 5 — Mini-cuestiones conceptuales

(a) Ventaja de separar las dos aulas en VLAN distintas frente a una red plana:

• Seguridad: cada VLAN es un dominio de difusión y de seguridad aislado. El tráfico de una VLAN no es visible para la otra salvo que el router/L3 lo permita, de modo que un equipo comprometido o un sniffer en Aula 2 no puede captar el tráfico de Aula 1. Permite aplicar ACL inter-VLAN y políticas diferenciadas (la base de la C3).
• Rendimiento: se reduce el dominio de broadcast. En una red plana, cada broadcast (ARP, DHCP, descubrimientos) lo procesan TODOS los equipos; al segmentar, los broadcasts quedan confinados a su VLAN, disminuyendo el tráfico inútil y la carga de CPU de los hosts, y conteniendo posibles tormentas de broadcast.

(b) Por qué conviene que el DNS interno resuelva el dominio local en lugar de delegar todo a 8.8.8.8:

• Resolución de nombres locales: servicios internos (Moodle, web interna, impresoras, recursos del IES) tienen nombres del dominio local (*.ies-serracalderona.local) que un DNS público desconoce; solo el DNS interno los resuelve.
• Rendimiento y disponibilidad: el DNS interno cachea las consultas, responde en LAN con baja latencia y permite navegar/usar servicios internos aunque la línea de Internet falle. Reduce además el volumen de consultas externas.
• Control y seguridad: permite filtrado/registro de consultas, split-horizon (vistas internas/externas), y forzar políticas (bloqueo de dominios) que con un resolutor público delegado no se podrían aplicar. El esquema correcto es: DNS interno autoritativo del dominio local + forwarders hacia 8.8.8.8 (u otro) para el resto de Internet.