1.5 VLANs

Las VLANs son la herramienta que usan los entornos corporativos reales para segmentar la red. Entenderlas es imprescindible tanto para atacarlas como para construir laboratorios que las simulen. Y lo mejor: puedes implementarlas completamente en software, sin un switch físico.

1.5.1 ¿Qué es una VLAN y para qué sirve?

Una VLAN (Virtual Local Area Network) es una red lógica creada sobre una infraestructura física compartida. Permite dividir un mismo switch físico — o un conjunto de switches — en múltiples redes aisladas, como si cada una tuviera su propio hardware independiente.

Sin VLANs, todos los dispositivos conectados a un switch comparten el mismo dominio de broadcast: cualquier trama enviada a la dirección de broadcast llega a todos. Con VLANs, el switch agrupa los puertos en segmentos lógicos separados — cada VLAN tiene su propio dominio de broadcast y los dispositivos de una VLAN no pueden comunicarse directamente con los de otra sin pasar por un router o un switch de capa 3.

Red plana vs red segmentada con VLANs — Red plana vs. red segmentada con VLANs. El hardware es el mismo; la segmentación es lógica.

Por qué importan las VLANs en seguridad

Las VLANs no son solo una herramienta de administración de redes. Son una capa de segmentación con implicaciones directas para el ataque y la defensa:

Contención de movimiento lateral: un atacante que compromete un equipo en una VLAN de usuarios no puede alcanzar directamente los servidores en la VLAN de producción — necesita atravesar un dispositivo de capa 3 donde puede haber ACLs y firewalls
Aislamiento de entornos: servidores críticos, dispositivos IoT, red de invitados, red de gestión — cada uno en su VLAN, con políticas de acceso independientes
VLAN hopping: cuando están mal configuradas, las VLANs pueden ser atravesadas por un atacante mediante técnicas como double tagging o switch spoofing — algo que veremos en los módulos de pentesting de red
Visibilidad del tráfico: un dispositivo en una VLAN solo ve el tráfico de su propio segmento — lo que limita la eficacia de ataques de sniffing pasivo

VLAN IDs y etiquetado

Cada VLAN tiene un identificador numérico llamado VLAN ID, un entero entre 1 y 4094. El rango 1-1005 es el rango estándar (VLAN 1 es la VLAN nativa por defecto en switches Cisco — nunca debe usarse para tráfico de producción). El rango 1006-4094 es el rango extendido, disponible en switches más modernos.

El tráfico de VLAN se identifica mediante etiquetas de 4 bytes insertadas en la trama Ethernet según el estándar IEEE 802.1Q. La etiqueta incluye el VLAN ID y la prioridad de tráfico (802.1p). Cuando una trama sin etiquetar entra por un puerto de acceso, el switch le asigna la VLAN configurada para ese puerto. Cuando la trama viaja por un enlace trunk, lleva su etiqueta 802.1Q visible.

Tipos de puertos: access vs trunk

Tipo de puerto	Función	Tráfico	Dónde se usa
Access	Conecta dispositivos finales a una VLAN específica	Sin etiquetar (el dispositivo no sabe que está en una VLAN)	PCs, impresoras, cámaras, teléfonos IP
Trunk	Transporta tráfico de múltiples VLANs simultáneamente	Etiquetado 802.1Q (cada trama lleva su VLAN ID)	Enlace switch-switch, switch-router, switch-hypervisor

💡

La VLAN nativa en trunks: En un enlace trunk 802.1Q, la VLAN nativa es la única cuyo tráfico viaja sin etiquetar. Por defecto es la VLAN 1 en la mayoría de switches. Esto es relevante para el ataque de double tagging: si el atacante está en la VLAN nativa y envía una trama con doble etiqueta (VLAN nativa exterior + VLAN objetivo interior), el primer switch elimina la etiqueta exterior y el segundo switch reenvía la trama a la VLAN objetivo — saltando el aislamiento. La contramedida es cambiar la VLAN nativa a una VLAN sin uso y nunca asignar puertos de acceso a ella.

1.5.2 VLANs sin hardware: aislar clientes con redes internas

No necesitas un switch gestionable de Cisco para practicar con VLANs. En un laboratorio virtual puedes simular la segmentación de VLANs usando las redes internas del hypervisor — que conceptualmente hacen exactamente lo mismo: grupos de máquinas que solo se ven entre sí, aisladas del resto.

Esta aproximación es perfecta para entender los principios de segmentación y para practicar ataques de movimiento lateral antes de pasar a implementaciones con 802.1Q real.

Simulación de VLANs con redes internas en laboratorio virtual — Simulación de VLANs con redes internas del hypervisor. Cada red interna es una VLAN lógica — sin hardware físico.

Mapeo entre VLANs y redes internas

Cada red interna del hypervisor actúa como una VLAN independiente:

topología — VLANs simuladas en VirtualBox

## SIMULACIÓN DE RED CORPORATIVA CON 3 VLANs

# VLAN 10 — Red de usuarios (Internal Network: "vlan-usuarios")
PC-Usuario-1:   Adaptador 1: Internal "vlan-usuarios"   # 10.10.10.x
PC-Usuario-2:   Adaptador 1: Internal "vlan-usuarios"   # 10.10.10.x

# VLAN 20 — Servidores (Internal Network: "vlan-servidores")
Servidor-Web:   Adaptador 1: Internal "vlan-servidores"  # 10.20.20.x
Servidor-DB:    Adaptador 1: Internal "vlan-servidores"  # 10.20.20.x

# VLAN 30 — Gestión (Internal Network: "vlan-gestion")
Switch-Mgmt:    Adaptador 1: Internal "vlan-gestion"     # 10.30.30.x

# ROUTER VIRTUAL — tiene una pata en cada VLAN
Router-VM:
  Adaptador 1: Internal "vlan-usuarios"   # Gateway 10.10.10.1
  Adaptador 2: Internal "vlan-servidores" # Gateway 10.20.20.1
  Adaptador 3: Internal "vlan-gestion"    # Gateway 10.30.30.1
  Adaptador 4: NAT                        # Salida a internet

# Sin el router, las VLANs están completamente aisladas entre sí
# Con el router, el tráfico inter-VLAN pasa por él (donde se aplican ACLs)

Escenario de laboratorio: compromiso y movimiento lateral

Con esta topología puedes practicar un escenario completo de movimiento lateral:

Comprometer un PC de la VLAN de usuarios (explotación de vulnerabilidad, phishing, etc.)
Enumerar la red local: el atacante ve 10.10.10.0/24 pero no ve 10.20.20.0/24 directamente
Identificar el gateway: 10.10.10.1 es el router virtual — el único camino hacia los servidores
Intentar acceder a los servidores a través del router: si el router tiene ACLs, el tráfico puede estar bloqueado; si no las tiene, puede ser posible el acceso directo
Pivotar: usar la máquina comprometida como pivot para alcanzar la VLAN de servidores

💡

Diferencia con 802.1Q real: En esta simulación, el aislamiento lo hace el hypervisor — las redes internas son realmente independientes. En un entorno físico con 802.1Q, el aislamiento lo hace el switch mediante etiquetas en las tramas. El comportamiento funcional es idéntico para practicar los conceptos; la diferencia está en la capa de implementación.

Asignar IPs en redes internas sin DHCP

Las redes internas del hypervisor no tienen DHCP por defecto (a diferencia de NAT o Host-Only). Tienes que asignar IPs estáticas a las VMs o añadir un servidor DHCP en la red.

bash — IP estática en Linux (dentro de la VM)

# Ver interfaces disponibles
ip link show

# Asignar IP estática temporal (no persiste al reiniciar)
ip addr add 10.10.10.11/24 dev eth0
ip link set eth0 up

# Asignar gateway (si hay router en la red)
ip route add default via 10.10.10.1

# IP estática permanente en Debian/Ubuntu (netplan)
# Editar /etc/netplan/00-installer-config.yaml:
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.10.10.11/24]
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses: [8.8.8.8]

netplan apply

# IP estática en Red Hat / CentOS / Rocky (nmcli)
nmcli con mod "Wired connection 1" \
    ipv4.method manual \
    ipv4.addresses 10.10.10.11/24 \
    ipv4.gateway 10.10.10.1
nmcli con up "Wired connection 1"

1.5.3 VLANs 802.1Q en Linux: bridges en el anfitrión

Cuando quieres implementar VLANs reales con etiquetado 802.1Q — no solo simularlas con redes internas — Linux tiene soporte nativo completo. Puedes crear interfaces VLAN, bridges y configurar trunk links directamente desde el kernel, sin hardware adicional.

Esta configuración es especialmente útil si tienes un switch gestionable real en tu laboratorio, si usas KVM como hypervisor, o si quieres entender exactamente cómo funciona el etiquetado a nivel de paquetes.

Subinterfaces VLAN (802.1Q tagging)

Linux permite crear subinterfaces virtuales sobre una interfaz física, cada una asociada a un VLAN ID. El kernel añade o elimina automáticamente las etiquetas 802.1Q al enviar y recibir tráfico.

bash — subinterfaces VLAN con ip link

# Cargar el módulo 8021q si no está cargado
modprobe 8021q

# Verificar que está cargado
lsmod | grep 8021q

# Crear subinterfaz VLAN 10 sobre eth0
ip link add link eth0 name eth0.10 type vlan id 10
ip link set eth0.10 up
ip addr add 10.10.10.1/24 dev eth0.10

# Crear subinterfaz VLAN 20 sobre eth0
ip link add link eth0 name eth0.20 type vlan id 20
ip link set eth0.20 up
ip addr add 10.20.20.1/24 dev eth0.20

# Crear subinterfaz VLAN 30
ip link add link eth0 name eth0.30 type vlan id 30
ip link set eth0.30 up
ip addr add 10.30.30.1/24 dev eth0.30

# Ver las subinterfaces creadas
ip link show type vlan

# Ver detalles de una subinterfaz VLAN (incluye el VLAN ID)
ip -d link show eth0.10

# Capturar tráfico etiquetado 802.1Q en la interfaz física
tcpdump -i eth0 -e 'vlan'

# Capturar solo tráfico de VLAN 10
tcpdump -i eth0 -e 'vlan 10'

Bridges Linux con VLANs

Un bridge Linux actúa como un switch software de capa 2. Cuando combinas bridges con subinterfaces VLAN, puedes construir una infraestructura de switching completa en software — útil para conectar VMs de KVM a VLANs específicas.

bash — bridge Linux con VLAN filtering

# Crear un bridge con soporte de VLAN filtering (kernel >= 3.9)
ip link add name br0 type bridge vlan_filtering 1
ip link set br0 up

# Añadir interfaz física al bridge (actúa como puerto trunk)
ip link set eth0 master br0
ip link set eth0 up

# Configurar eth0 como puerto trunk (permite VLANs 10, 20 y 30)
bridge vlan add dev eth0 vid 10 trunk
bridge vlan add dev eth0 vid 20 trunk
bridge vlan add dev eth0 vid 30 trunk

# Añadir una interfaz de VM (vnet0) al bridge como puerto access VLAN 10
ip link set vnet0 master br0
bridge vlan add dev vnet0 vid 10 pvid untagged master

# Otra VM (vnet1) en VLAN 20
ip link set vnet1 master br0
bridge vlan add dev vnet1 vid 20 pvid untagged master

# Ver tabla de VLANs del bridge
bridge vlan show

# Ver tabla de MACs aprendidas por el bridge
bridge fdb show

Hacer la configuración persistente

Los comandos anteriores son temporales — desaparecen al reiniciar. Para persistirlos hay dos aproximaciones: usar systemd-networkd (recomendado en servidores) o editar la configuración de netplan (Ubuntu) o los archivos de interfaz de NetworkManager.

bash — VLANs persistentes con systemd-networkd

# Archivo: /etc/systemd/network/10-eth0.network
# Configurar eth0 como interfaz base (sin IP, solo para el bridge/VLAN)
[Match]
Name=eth0

[Network]
VLAN=eth0.10
VLAN=eth0.20
VLAN=eth0.30

---

# Archivo: /etc/systemd/network/20-vlan10.netdev
# Definir la subinterfaz VLAN 10
[NetDev]
Name=eth0.10
Kind=vlan

[VLAN]
Id=10

---

# Archivo: /etc/systemd/network/20-vlan10.network
# Asignar IP a VLAN 10
[Match]
Name=eth0.10

[Network]
Address=10.10.10.1/24

---

# Repetir los dos últimos archivos para VLAN 20 y 30
# Activar y reiniciar systemd-networkd
systemctl enable systemd-networkd
systemctl restart systemd-networkd

# Verificar el estado
networkctl status

⚠️

NetworkManager vs systemd-networkd: En muchas distribuciones de escritorio, NetworkManager gestiona las interfaces y puede entrar en conflicto con la configuración manual de bridges y VLANs. Si usas NetworkManager, deshabilita su gestión de la interfaz que vas a usar para VLANs añadiendo NM_CONTROLLED=no en su configuración, o usa nmcli para crear las VLANs directamente desde NetworkManager.

Verificar el etiquetado con tcpdump y Wireshark

bash — verificación de etiquetado 802.1Q

# Capturar tramas 802.1Q en la interfaz física (verás las etiquetas)
tcpdump -i eth0 -e -nn 'vlan'

# Ejemplo de salida con trama etiquetada VLAN 10:
# 14:32:01 AA:BB:CC:DD:EE:FF > FF:FF:FF:FF:FF:FF, ethertype 802.1Q (0x8100),
# vlan 10, p 0, ethertype ARP, Request who-has 10.10.10.1 tell 10.10.10.11

# Verificar que las subinterfaces NO ven tráfico de otras VLANs
tcpdump -i eth0.10 -nn    # Solo tráfico VLAN 10, sin etiquetar
tcpdump -i eth0.20 -nn    # Solo tráfico VLAN 20, sin etiquetar

# Generar tráfico de prueba entre VMs en VLANs distintas
# (desde VM en VLAN 10, intentar ping a VM en VLAN 20)
ping -c 3 10.20.20.11
# Debe fallar si no hay router inter-VLAN configurado

1.5.4 Router virtual como switch VLAN

Las VLANs aíslan el tráfico en capa 2, pero en una red real los equipos de VLANs distintas necesitan comunicarse — bajo condiciones controladas. Para eso se necesita enrutamiento inter-VLAN: un dispositivo de capa 3 que conecte los segmentos y aplique las políticas de acceso entre ellos.

En un entorno físico esto lo hace un switch de capa 3 o un router con subinterfaces. En el laboratorio lo hace una VM Linux configurada como router, usando exactamente los mismos conceptos: subinterfaces 802.1Q + IP forwarding + reglas de firewall.

Router-on-a-stick

La técnica router-on-a-stick consiste en conectar el router al switch mediante un único enlace trunk que transporta todas las VLANs. El router crea subinterfaces para cada VLAN y enruta el tráfico entre ellas. Es la forma más eficiente de hacer enrutamiento inter-VLAN sin necesitar un puerto físico por VLAN.

bash — router-on-a-stick en Linux

## CONFIGURACIÓN DEL ROUTER VIRTUAL
# La VM tiene eth0 conectada al trunk (Internal Network del hypervisor)

# 1. Habilitar IP forwarding (enrutamiento entre interfaces)
echo 1 > /proc/sys/net/ipv4/ip_forward

# Para que persista al reiniciar:
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

# 2. Crear subinterfaces VLAN (gateway de cada segmento)
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.10.10.1/24 dev eth0.10   # Gateway VLAN 10
ip link set eth0.10 up

ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.20.20.1/24 dev eth0.20   # Gateway VLAN 20
ip link set eth0.20 up

ip link add link eth0 name eth0.30 type vlan id 30
ip addr add 10.30.30.1/24 dev eth0.30   # Gateway VLAN 30
ip link set eth0.30 up

# 3. Verificar tabla de rutas (debe tener una ruta por cada subred)
ip route show

Control de tráfico inter-VLAN con iptables

Con IP forwarding activo, el router enruta tráfico entre todas las VLANs sin restricciones. En un entorno real, eso no es lo que quieres — las VLANs existen precisamente para segmentar. Las reglas de iptables implementan las políticas de acceso entre segmentos.

bash — políticas inter-VLAN con iptables

## POLÍTICA DE EJEMPLO:
## - VLAN 10 (usuarios) puede acceder a VLAN 20 (servidores) solo por HTTP/HTTPS
## - VLAN 10 NO puede acceder a VLAN 30 (gestión)
## - VLAN 30 puede acceder a todas las VLANs (administradores)
## - Respuestas establecidas siempre permitidas

# Política por defecto: DROP en FORWARD (todo denegado hasta que se permita)
iptables -P FORWARD DROP

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

# VLAN 10 → VLAN 20: solo HTTP (80) y HTTPS (443)
iptables -A FORWARD -i eth0.10 -o eth0.20 -p tcp \
    --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0.10 -o eth0.20 -p tcp \
    --dport 443 -j ACCEPT

# VLAN 10 → VLAN 30: denegado (no hay regla ACCEPT, cae en la política DROP)

# VLAN 30 (gestión) → todas las VLANs: acceso completo
iptables -A FORWARD -i eth0.30 -j ACCEPT

# Ver las reglas activas
iptables -L FORWARD -v --line-numbers

# Guardar las reglas para que persistan al reiniciar (Debian/Ubuntu)
apt install iptables-persistent
netfilter-persistent save

NAT en el router virtual: dar internet a las VLANs

Si quieres que las VMs de las VLANs tengan acceso a internet a través del router virtual, añades una interfaz NAT al router y configuras masquerading:

bash — NAT para dar internet a las VLANs

# El router virtual tiene:
# eth0 → trunk con las VLANs (subinterfaces eth0.10, eth0.20, eth0.30)
# eth1 → NAT del hypervisor (acceso a internet)

# Habilitar NAT (masquerading) para todo el tráfico que sale por eth1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

# Permitir que las VLANs salgan a internet (a través del router)
iptables -A FORWARD -i eth0.10 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth0.20 -o eth1 -j ACCEPT

# VLAN 30 (gestión) sin internet — no añadir regla para eth0.30

# En cada VM de las VLANs, configurar el gateway como el router virtual
# VLAN 10: gateway = 10.10.10.1
# VLAN 20: gateway = 10.20.20.1

Laboratorio completo: topología con router virtual

Combinando todo lo visto en este apartado, la topología de laboratorio más completa que puedes construir sin hardware físico es:

topología — laboratorio completo con VLANs y router virtual

┌─────────────────────────────────────────────────────────────┐
│                    ANFITRIÓN (Linux/Windows)                │
│                                                             │
│  ┌──────────────┐     ┌──────────────────────────────────┐  │
│  │  KALI LINUX  │     │        ROUTER VIRTUAL            │  │
│  │  (atacante)  │     │  eth0.10 → 10.10.10.1/24         │  │
│  │              │     │  eth0.20 → 10.20.20.1/24         │  │
│  │  nic1: NAT   │     │  eth0.30 → 10.30.30.1/24         │  │
│  │  nic2: trunk │     │  eth1:   NAT (internet)          │  │
│  └──────┬───────┘     └────────────────┬─────────────────┘  │
│         │                              │ (trunk 802.1Q)     │
│      ───┴──────────────────────────────┴──────────────      │
│         Internal Network "trunk-lab" (VLAN 10/20/30)        │
│      ────────────┬──────────────────────────┬────────       │
│                  │                          │               │
│         ┌────────┴──────┐         ┌─────────┴─────────┐     │
│         │  VLAN 10      │         │  VLAN 20          │     │
│         │  PC-Usuario-1 │         │  Servidor-Web     │     │
│         │  10.10.10.11  │         │  10.20.20.11      │     │
│         │               │         │  Servidor-DB      │     │
│         │  PC-Usuario-2 │         │  10.20.20.12      │     │
│         │  10.10.10.12  │         └───────────────────┘     │
│         └───────────────┘                                   │
└─────────────────────────────────────────────────────────────┘

# Flujos de tráfico posibles:
# Kali → VLAN 10 directamente (misma red trunk)
# VLAN 10 → VLAN 20: solo HTTP/HTTPS (controlado por iptables del router)
# VLAN 10 → VLAN 30: bloqueado
# Kali puede pivotar: comprometer PC-Usuario → llegar a Servidor-Web

💡

Este laboratorio es tu base para los módulos de AD y pivoting: La topología con router virtual y VLANs simuladas es funcionalmente idéntica a una red corporativa real con segmentación. Cuando llegues al módulo 17 (Active Directory) o al 16 (Pivoting), puedes extender esta base añadiendo las VMs de Windows sin tener que reconstruir la red desde cero.

1.5.5 Ejercicio práctico: red segmentada con tres VLANs desde cero

Este ejercicio te guía paso a paso para montar una red completamente funcional con tres VLANs, un router virtual y una máquina atacante. Al terminar tendrás una topología real sobre la que practicar movimiento lateral, pivoting y segmentación — sin hardware físico.

Objetivo: construir esta red en VirtualBox (los conceptos son idénticos en VMware y KVM):

VM	SO recomendado	Adaptadores	IP	Rol
Kali	Kali Linux	NAT + Internal "lab-trunk"	10.10.10.10 (manual)	Atacante
Router	Debian/Ubuntu minimal	NAT + Internal "lab-trunk"	10.10.10.1 / 10.20.20.1 / 10.30.30.1	Router inter-VLAN
PC-Usuario	Debian/Ubuntu minimal	Internal "lab-trunk"	10.10.10.11	Cliente VLAN 10
Servidor-Web	Debian/Ubuntu minimal	Internal "lab-trunk"	10.20.20.11	Servidor VLAN 20

💡

Antes de empezar: Para el Router, PC-Usuario y Servidor-Web puedes usar la misma ISO de Debian o Ubuntu Server minimal — son VMs ligeras que no necesitan entorno gráfico. Con 512 MB de RAM y 8 GB de disco es suficiente para cada una. Kali necesita más recursos según tu configuración habitual.

Paso 1 — Crear las VMs y configurar los adaptadores de red

Crea las cuatro VMs en VirtualBox. La configuración de red de cada una es:

VirtualBox — configuración de red por VM

## VM: Kali
# Adaptador 1: NAT (internet para actualizar herramientas)
VBoxManage modifyvm "Kali" --nic1 nat
# Adaptador 2: Internal Network "lab-trunk" (acceso al laboratorio)
VBoxManage modifyvm "Kali" --nic2 intnet --intnet2 "lab-trunk"

## VM: Router
# Adaptador 1: NAT (para que el router pueda dar internet a las VLANs)
VBoxManage modifyvm "Router" --nic1 nat
# Adaptador 2: Internal Network "lab-trunk" (trunk con todas las VLANs)
VBoxManage modifyvm "Router" --nic2 intnet --intnet2 "lab-trunk"

## VM: PC-Usuario
# Adaptador 1: Internal Network "lab-trunk" (solo red interna)
VBoxManage modifyvm "PC-Usuario" --nic1 intnet --intnet1 "lab-trunk"

## VM: Servidor-Web
# Adaptador 1: Internal Network "lab-trunk" (solo red interna)
VBoxManage modifyvm "Servidor-Web" --nic1 intnet --intnet1 "lab-trunk"

⚠️

Importante: Todas las VMs usan la misma Internal Network "lab-trunk". Esto las conecta a nivel de capa 2 en el mismo segmento — como si estuvieran en el mismo switch. El aislamiento entre VLANs lo hará el etiquetado 802.1Q que configuramos en los pasos siguientes, no la separación del hypervisor.

Paso 1.5 (OPCIONAL) — Renombrar interfaces a eth0, eth1... en Debian/Ubuntu

Los sistemas modernos usan nombres de interfaz "predecibles" como enp0s3 o ens18 en lugar de los clásicos eth0, eth1. Todo el ejercicio funciona igual con cualquier nombre — simplemente sustituye eth0 por enp0s3 (o el nombre que tenga tu interfaz) en cada comando. Si prefieres usar los nombres clásicos para seguir el ejercicio sin adaptaciones, estos pasos lo consiguen. Aplícalos en cada VM antes de continuar.

⚠️

Haz esto antes de configurar la red. Si cambias los nombres después de tener la red configurada, el sistema buscará la interfaz antigua (por ejemplo enp0s3) al arrancar y perderá conectividad. Cambia el nombre primero, luego configura las IPs.

Paso A — Editar GRUB para desactivar los nombres predecibles:

bash — modificar GRUB

# Abrir el archivo de configuración de GRUB
sudo nano /etc/default/grub

# Buscar la línea GRUB_CMDLINE_LINUX y añadir los dos parámetros
# Si está vacía:
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

# Si ya tiene otros parámetros (por ejemplo "quiet splash"):
GRUB_CMDLINE_LINUX="quiet splash net.ifnames=0 biosdevname=0"

# Guardar (Ctrl+O → Enter) y salir (Ctrl+X)

# Aplicar los cambios en GRUB
sudo update-grub

net.ifnames=0 desactiva el esquema de nombres predecibles de systemd. biosdevname=0 desactiva el esquema alternativo de biosdevname. Con ambos a 0, el kernel vuelve al esquema clásico: eth0, eth1, wlan0...

Paso B — Actualizar la configuración de red antes de reiniciar:

bash — actualizar la configuración de red

# Si tu VM usa /etc/network/interfaces (Debian clásico):
sudo nano /etc/network/interfaces

# Cambiar el nombre antiguo por eth0. Ejemplo:
# Antes:
auto enp0s3
iface enp0s3 inet dhcp

# Después:
auto eth0
iface eth0 inet dhcp

# Si tu VM usa netplan (Ubuntu Server):
sudo nano /etc/netplan/00-installer-config.yaml
# Sustituir el nombre enp0s3 (o el que sea) por eth0 en el archivo YAML

Paso C — Reiniciar y verificar:

bash — reiniciar y confirmar

sudo reboot

# Tras el reinicio, verificar que las interfaces se llaman eth0, eth1...
ip link show
# Debes ver eth0 en lugar de enp0s3 o similar

Paso 2 — Configurar el Router (el más importante)

Arranca la VM Router. Identifica las interfaces con ip link show — tendrás eth0 (NAT, ya tiene IP por DHCP) y eth1 (lab-trunk, sin IP todavía). Ejecuta los siguientes comandos como root:

bash — VM Router (ejecutar como root)

# 1. Instalar herramientas necesarias
apt update && apt install -y iproute2 iptables tcpdump

# 2. Activar el reenvío de paquetes entre interfaces
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

# 3. Activar la interfaz del trunk sin asignarle IP (será el "cable" del switch)
ip link set eth1 up

# 4. Cargar el módulo 802.1Q
modprobe 8021q
echo "8021q" >> /etc/modules

# 5. Crear subinterfaz VLAN 10 — red de usuarios
ip link add link eth1 name eth1.10 type vlan id 10
ip addr add 10.10.10.1/24 dev eth1.10
ip link set eth1.10 up

# 6. Crear subinterfaz VLAN 20 — red de servidores
ip link add link eth1 name eth1.20 type vlan id 20
ip addr add 10.20.20.1/24 dev eth1.20
ip link set eth1.20 up

# 7. Crear subinterfaz VLAN 30 — red de gestión
ip link add link eth1 name eth1.30 type vlan id 30
ip addr add 10.30.30.1/24 dev eth1.30
ip link set eth1.30 up

# 8. Verificar que las tres subinterfaces tienen IP y están UP
ip addr show type vlan
# Debes ver eth1.10, eth1.20 y eth1.30 con sus IPs

# 9. Configurar NAT para dar internet a las VLANs (sale por eth0)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# 10. Política de reenvío: DROP por defecto (todo denegado hasta que se permita)
iptables -P FORWARD DROP

# 11. Permitir respuestas de conexiones ya establecidas
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# 12. VLAN 10 → internet: permitido
iptables -A FORWARD -i eth1.10 -o eth0 -j ACCEPT

# 13. VLAN 10 → VLAN 20: solo HTTP (80) y HTTPS (443)
iptables -A FORWARD -i eth1.10 -o eth1.20 -p tcp \
    -m multiport --dports 80,443 -j ACCEPT

# 14. VLAN 10 → VLAN 30: bloqueado (no hay regla, cae en DROP)

# 15. VLAN 20 → internet: permitido
iptables -A FORWARD -i eth1.20 -o eth0 -j ACCEPT

# 16. VLAN 30 (gestión) → todo: acceso completo
iptables -A FORWARD -i eth1.30 -j ACCEPT

# 17. Bloquear acceso desde VLAN 10 y 20 a la interfaz de gestión del router
# (el tráfico hacia IPs del propio router usa la cadena INPUT, no FORWARD)
iptables -A INPUT -i eth1.10 -d 10.30.30.1 -j DROP
iptables -A INPUT -i eth1.20 -d 10.30.30.1 -j DROP

# 18. Verificar las reglas
iptables -L FORWARD -v --line-numbers
iptables -L INPUT -v --line-numbers
iptables -t nat -L -v

Paso 3 — Configurar PC-Usuario (VLAN 10)

Arranca la VM PC-Usuario. Tiene una sola interfaz conectada a lab-trunk. Necesita una subinterfaz etiquetada con VLAN 10 para que el router la reconozca en el segmento correcto:

bash — VM PC-Usuario (ejecutar como root)

# 1. Configurar DNS antes de cualquier apt (sin esto no hay resolución de nombres)
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 1.1.1.1" >> /etc/resolv.conf

# 2. Instalar herramientas
apt update && apt install -y iproute2 iputils-ping curl

# 3. Identificar la interfaz (probablemente eth0)
ip link show

# 4. Cargar módulo 802.1Q
modprobe 8021q

# 5. Activar la interfaz física sin IP
ip link set eth0 up

# 6. Crear subinterfaz etiquetada VLAN 10
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.10.10.11/24 dev eth0.10
ip link set eth0.10 up

# 7. Añadir ruta por defecto apuntando al gateway (el router)
ip route add default via 10.10.10.1

# 8. Verificar configuración
ip addr show eth0.10
ip route show
ping -c 2 8.8.8.8       # Verificar que hay internet
nslookup google.com      # Verificar que el DNS resuelve

Paso 4 — Configurar Servidor-Web (VLAN 20)

Misma lógica que el PC-Usuario, pero con VLAN ID 20 y en la subred de servidores. Además instalaremos un servidor web mínimo para poder probar la política de acceso:

bash — VM Servidor-Web (ejecutar como root)

# 1. Configurar DNS antes de cualquier apt
echo "nameserver 8.8.8.8" > /etc/resolv.conf
echo "nameserver 1.1.1.1" >> /etc/resolv.conf

# 2. Instalar herramientas y servidor web
apt update && apt install -y iproute2 iputils-ping nginx

# 3. Cargar módulo 802.1Q
modprobe 8021q

# 4. Activar interfaz física sin IP
ip link set eth0 up

# 5. Crear subinterfaz etiquetada VLAN 20
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.20.20.11/24 dev eth0.20
ip link set eth0.20 up

# 6. Ruta por defecto
ip route add default via 10.20.20.1

# 7. Arrancar nginx y crear una página de prueba
systemctl start nginx
echo "<h1>Servidor-Web VLAN 20 funcionando</h1>" > /var/www/html/index.html

# 8. Verificar que nginx está escuchando
ss -tlnp | grep :80

Paso 5 — Configurar Kali (acceso directo al trunk)

Kali actúa como atacante externo. La conectamos a la red lab-trunk en VLAN 10 — como si fuera un equipo más de la red de usuarios que ha sido comprometido, o directamente en el segmento trunk para tener visibilidad total:

bash — VM Kali (ejecutar como root)

# eth0 es el adaptador NAT (ya tiene IP automática por DHCP)
# eth1 es el adaptador de lab-trunk

# Activar eth1 sin IP (interfaz trunk)
ip link set eth1 up

# Crear subinterfaz VLAN 10 (Kali "dentro" de la VLAN de usuarios)
ip link add link eth1 name eth1.10 type vlan id 10
ip addr add 10.10.10.10/24 dev eth1.10
ip link set eth1.10 up
ip route add 10.10.10.0/24 dev eth1.10

# Ruta hacia la VLAN 20 a través del router (para comprobar políticas)
ip route add 10.20.20.0/24 via 10.10.10.1
ip route add 10.30.30.0/24 via 10.10.10.1

# Verificar tabla de rutas
ip route show

Paso 6 — Verificar que todo funciona correctamente

Con las cuatro VMs configuradas, ejecuta estas comprobaciones desde Kali para confirmar que la red y las políticas funcionan como se esperan:

bash — verificaciones desde Kali

## ✅ DEBE FUNCIONAR

# Kali puede hacer ping al PC-Usuario (misma VLAN 10)
ping -c 3 10.10.10.11
# → 3 packets transmitted, 3 received

# Kali puede hacer ping al router (gateway de VLAN 10)
ping -c 3 10.10.10.1
# → 3 packets transmitted, 3 received

# Kali puede acceder al servidor web en VLAN 20 por HTTP (permitido por iptables)
curl -s http://10.20.20.11
# → <h1>Servidor-Web VLAN 20 funcionando</h1>

## ❌ DEBE FALLAR

# Kali NO puede hacer ping al Servidor-Web (ICMP no está permitido entre VLANs)
ping -c 3 10.20.20.11
# → 100% packet loss (bloqueado por iptables)

# Kali NO puede acceder a la VLAN 30 (gestión)
ping -c 3 10.30.30.1
# → 100% packet loss (bloqueado por iptables INPUT en el router)
# Nota: esta regla va en INPUT, no en FORWARD, porque 10.30.30.1 es
# la IP de la interfaz del propio router — el tráfico hacia ella
# no atraviesa FORWARD sino que llega directamente al proceso del router

## 🔍 DIAGNÓSTICO

# Ver el tráfico etiquetado en el trunk desde el Router
# (ejecutar en la VM Router mientras haces las pruebas desde Kali)
tcpdump -i eth1 -e -nn 'vlan'
# Verás las etiquetas 802.1Q: "vlan 10", "vlan 20"...

# Ver los contadores de iptables (si una regla tiene hits, el tráfico la está usando)
iptables -L FORWARD -v --line-numbers

Paso 7 — Hacer la configuración persistente

Todo lo configurado hasta ahora se pierde al reiniciar. Para que sobreviva, guarda la configuración en cada VM:

bash — persistencia con un script de arranque (todas las VMs)

## OPCIÓN RÁPIDA: script en /etc/rc.local
## (funciona en Debian/Ubuntu, no requiere conocer systemd-networkd)

# En la VM Router, crear /etc/rc.local:
cat > /etc/rc.local << 'EOF'
#!/bin/bash
modprobe 8021q
ip link set eth1 up
ip link add link eth1 name eth1.10 type vlan id 10
ip addr add 10.10.10.1/24 dev eth1.10
ip link set eth1.10 up
ip link add link eth1 name eth1.20 type vlan id 20
ip addr add 10.20.20.1/24 dev eth1.20
ip link set eth1.20 up
ip link add link eth1 name eth1.30 type vlan id 30
ip addr add 10.30.30.1/24 dev eth1.30
ip link set eth1.30 up
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1.10 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth1.10 -o eth1.20 -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A FORWARD -i eth1.20 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth1.30 -j ACCEPT
iptables -A INPUT -i eth1.10 -d 10.30.30.1 -j DROP
iptables -A INPUT -i eth1.20 -d 10.30.30.1 -j DROP
exit 0
EOF

chmod +x /etc/rc.local
systemctl enable rc-local
systemctl start rc-local

## En PC-Usuario, crear /etc/rc.local:
cat > /etc/rc.local << 'EOF'
#!/bin/bash
modprobe 8021q
ip link set eth0 up
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.10.10.11/24 dev eth0.10
ip link set eth0.10 up
ip route add default via 10.10.10.1
exit 0
EOF
chmod +x /etc/rc.local
systemctl enable rc-local

## En Servidor-Web, crear /etc/rc.local:
cat > /etc/rc.local << 'EOF'
#!/bin/bash
modprobe 8021q
ip link set eth0 up
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.20.20.11/24 dev eth0.20
ip link set eth0.20 up
ip route add default via 10.20.20.1
exit 0
EOF
chmod +x /etc/rc.local
systemctl enable rc-local

Paso 8 — Tomar snapshots del estado funcional

Con todo funcionando y verificado, toma un snapshot de cada VM. Este es tu punto de restauración — si algo se rompe durante las prácticas, puedes volver aquí en segundos.

bash — snapshots desde el anfitrión

# Tomar snapshot de cada VM (con la VM apagada para snapshot limpio)
VBoxManage snapshot "Kali"        take "lab-vlans-ok" --description "Red VLAN funcional"
VBoxManage snapshot "Router"      take "lab-vlans-ok" --description "Router configurado"
VBoxManage snapshot "PC-Usuario"  take "lab-vlans-ok" --description "VLAN 10 funcional"
VBoxManage snapshot "Servidor-Web" take "lab-vlans-ok" --description "VLAN 20 funcional"

# Para restaurar cualquier VM a este estado:
VBoxManage snapshot "Router" restore "lab-vlans-ok"

💡

¿Qué tienes ahora? Una red corporativa simulada con tres segmentos aislados, un router con políticas de acceso, y una máquina atacante con visibilidad parcial. Las prácticas que puedes hacer sobre esta base: escaneo de red con nmap para descubrir hosts en cada VLAN, explotación del PC-Usuario y uso de la máquina comprometida como pivot para alcanzar el Servidor-Web, análisis del tráfico 802.1Q con tcpdump y Wireshark, y más adelante — cuando llegues al módulo 16 — configurar chisel o ligolo-ng como canal de pivoting a través del router.