eClassVirtual

**¡Ya está disponible Ethical Hacking desde Cero!**

Hace unos días les comenté que estaba preparando este nuevo material y varios me preguntaron cuándo estaría disponible.

Bueno… **ya está listo. 🔐**

Creé **Ethical Hacking desde Cero** pensando especialmente en quienes quieren comenzar en ciberseguridad, pero muchas veces se encuentran con demasiados conceptos, herramientas y comandos y no saben por dónde empezar.

La idea no es que simplemente copies comandos.

👉 Quiero que entiendas **qué estás haciendo, por qué lo estás haciendo y cómo interpretar los resultados**.

Dentro encontrarás:

✅ Explicaciones desde las bases
✅ 10 laboratorios prácticos paso a paso
✅ Capturas de laboratorios reales
✅ Challenge final
✅ Metodología: **Descubrir → Analizar → Validar → Proteger**

Y además incluí **4 bonos**

🤖 **CyberLab AI** — Tutor con IA para acompañarte mientras estudias.

🛡️ **Blue Team desde Cero** — Para comenzar a conocer también el lado defensivo.

📋 **Cybersecurity Cheat Sheet** — Conceptos y referencias importantes siempre a mano.

🧭 **Ruta Profesional Cybersecurity** — Para conocer las distintas áreas y saber cómo continuar tu aprendizaje.

🔥 **Precio especial de lanzamiento: US$8,99**

Si eres de los que me preguntaron cuándo estaría disponible, aquí lo tienes 👇

🔗 https://eclassvirtual.com/ebook-ethical-hacking-desde-cero/

**Empieza desde las bases. Entiende lo que haces. Y sigue avanzando.**

𝐐𝐮𝐢𝐞𝐫𝐞𝐬 𝐭𝐫𝐚𝐛𝐚𝐣𝐚𝐫 𝐞𝐧 𝐂𝐢𝐛𝐞𝐫𝐬𝐞𝐠𝐮𝐫𝐢𝐝𝐚𝐝❓ 𝐍𝐨 𝐭𝐨𝐝𝐨 𝐞𝐬 𝐩𝐞𝐧𝐭𝐞𝐬𝐭𝐢𝐧𝐠.

Cuando alguien comienza a interesarse por ciberseguridad, es común pensar inmediatamente en hacking ético, Kali Linux o pruebas de penetración.

Pero el campo es mucho más amplio.

Dependiendo de tus conocimientos y de lo que te guste hacer, puedes terminar trabajando en áreas muy distintas:

🔹 SOC / Analista de Seguridad: monitorea alertas, analiza eventos y detecta posibles amenazas.

🔹 Pentesting: realiza pruebas de seguridad autorizadas para identificar vulnerabilidades, validarlas y demostrar su impacto.

🔹 Ingeniería de Seguridad: implementa y administra controles como firewalls, VPN, IDS/IPS, EDR y otras tecnologías de protección.

🔹 Respuesta a Incidentes: investiga qué ocurrió, contiene el incidente, ayuda a erradicar la amenaza y participa en la recuperación.

🔹 Forense Digital: analiza equipos, registros y evidencia digital para reconstruir un incidente.

🔹 Cloud Security: protege identidades, redes, cargas de trabajo y datos en plataformas cloud.

🔹 Application Security: busca reducir vulnerabilidades en aplicaciones, APIs y procesos de desarrollo.

🔹 GRC: trabaja con riesgos, controles, auditorías, normativas y cumplimiento.

🔹 Arquitectura de Seguridad: diseña cómo deben integrarse los distintos controles de seguridad dentro de una organización.

Y todavía quedan otras áreas: Threat Hunting, Threat Intelligence, IAM/PAM, DevSecOps, Malware Analysis y seguridad OT/ICS, entre otras.

𝐀𝐥𝐠𝐨 𝐪𝐮𝐞 𝐚 𝐯𝐞𝐜𝐞𝐬 𝐬𝐞 𝐩𝐚𝐬𝐚 𝐩𝐨𝐫 𝐚𝐥𝐭𝐨: 𝐧𝐨 𝐧𝐞𝐜𝐞𝐬𝐢𝐭𝐚𝐬 𝐜𝐨𝐦𝐞𝐧𝐳𝐚𝐫 𝐝𝐞𝐬𝐝𝐞 𝐜𝐞𝐫𝐨 𝐬𝐢 𝐲𝐚 𝐭𝐫𝐚𝐛𝐚𝐣𝐚𝐬 𝐞𝐧 𝐓𝐈.

Si vienes de redes, por ejemplo, ya tienes una base muy útil: TCP/IP, routing, switching, VLAN, DNS, DHCP, NAT, VPN, ACL y troubleshooting.

Después puedes profundizar en firewalls, análisis de tráfico, hardening, detección de amenazas y respuesta a incidentes.

La ciberseguridad no es un único cargo ni existe una sola ruta para entrar.

¿En cuál de estas áreas te gustaría especializarte?

𝐇𝐨𝐲 𝐮𝐧 𝐞𝐬𝐭𝐮𝐝𝐢𝐚𝐧𝐭𝐞 𝐦𝐞 𝐩𝐥𝐚𝐧𝐭𝐞𝐨́ 𝐮𝐧 𝐩𝐫𝐨𝐛𝐥𝐞𝐦𝐚 𝐢𝐧𝐭𝐞𝐫𝐞𝐬𝐚𝐧𝐭𝐞.

Tenía conectividad con un equipo de red:

Ping respondía.
Telnet funcionaba.
SSH no conectaba.

A primera vista, todo apuntaba al equipo.

¿SSH estaba habilitado? ¿Problema con las líneas VTY? ¿Usuario o contraseña? ¿Claves RSA? ¿Alguna configuración de autenticación?

Pero había una pista importante.

Si el equipo responde al ping, sabemos que para esa prueba existe comunicación ICMP entre origen y destino.

Y si además podemos conectarnos por Telnet, sabemos que una sesión TCP hacia el equipo puede establecerse, en este caso utilizando TCP/23.

Entonces la pregunta cambió:

¿Qué está pasando específicamente con TCP/22?

Ahí comenzamos a mirar más allá del equipo.

Finalmente encontramos la causa: había un firewall en el camino que permitía TCP/23, pero estaba bloqueando TCP/22.

Telnet → TCP/23 → pasa
SSH → TCP/22 → bloqueado

Este tipo de problemas muestra por qué no basta con hacer un ping y concluir que “la red está bien”.

Cuando falla un servicio específico, también podemos probar directamente el puerto:

telnet 22

En Linux:

nc -vz 22

Y si queremos profundizar, una captura con Wireshark puede entregar pistas sobre el establecimiento de la sesión TCP.

Por ejemplo:

Cliente → Servidor: SYN
Cliente → Servidor: SYN (Retransmission)
Cliente → Servidor: SYN (Retransmission)

Si no aparece el correspondiente SYN/ACK, el three-way handshake TCP no se está completando.

Eso por sí solo no demuestra que sea un firewall. El tráfico podría estar siendo descartado por una ACL, un firewall, existir un problema de retorno o incluso no estar disponible el servicio en el destino. Hay que seguir investigando.

En este caso, el firewall era el responsable.

Una buena regla para troubleshooting:

Ping responde ≠ todos los servicios están disponibles.

Cuando algo no funciona, no revises solamente el origen y el destino.

Revisa el camino completo:

Origen → Red → ACL/Firewall → Destino → Servicio

A veces el equipo está perfectamente configurado y el problema está en el camino.

¿Qué habrías revisado tú primero?

𝐄𝐥 𝐩𝐮𝐞𝐫𝐭𝐨 𝐞𝐬𝐭𝐚́ 𝐔𝐏… ¿𝐩𝐞𝐫𝐨 𝐫𝐞𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐞𝐬𝐭𝐚́ 𝐟𝐮𝐧𝐜𝐢𝐨𝐧𝐚𝐧𝐝𝐨 𝐛𝐢𝐞𝐧❓

Que una interfaz de un switch Cisco aparezca up/up no significa que esté sana.

Cuando hay lentitud, pérdida de paquetes o conexiones intermitentes, uno de los primeros comandos que conviene revisar es:

𝐬𝐡𝐨𝐰 𝐢𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞𝐬 𝐆𝐢𝐠𝐚𝐛𝐢𝐭𝐄𝐭𝐡𝐞𝐫𝐧𝐞𝐭𝟏/𝟎/𝟏𝟎

Y antes de mirar veinte contadores, yo revisaría estos:

CRC errors
Si aumentan constantemente, hay que mirar la capa física: cableado, conectores, patch cord, SFP/transceiver, NIC o el propio puerto.

Input errors
Indican que el switch está recibiendo tramas con problemas. No explican por sí solos la causa; hay que correlacionarlos con CRC, runts, giants y otros contadores.

Output drops
Aquí el problema puede ser completamente distinto. El switch recibió correctamente el tráfico, pero no pudo transmitirlo todo. Una causa frecuente es congestión en la cola de salida.

Late collisions
En una red Ethernet moderna trabajando en full-duplex no deberían ser normales. Si aparecen, revisaría inmediatamente negociación de velocidad/duplex y la capa física.

Por ejemplo:

GigabitEthernet1/0/10 is up, line protocol is up
5 minute input rate 82000000 bits/sec
5 minute output rate 940000000 bits/sec
1847 input errors, 1812 CRC
0 collisions, 0 late collision
32641 total output drops

La interfaz está UP/UP.

𝐏𝐞𝐫𝐨 𝐜𝐥𝐚𝐫𝐚𝐦𝐞𝐧𝐭𝐞 𝐧𝐨 𝐞𝐬𝐭𝐚́ 𝐬𝐚𝐧𝐚.

Y lo interesante es que probablemente tenemos dos pistas diferentes: los CRC apuntan hacia recepción/capa física, mientras que los output drops obligan a investigar qué está pasando con la salida y sus colas.

Por eso, cuando alguien dice:

“El puerto está arriba, así que está bien”

todavía falta revisar bastante. 😅

¿En qué contador te fijarías primero?

𝐐𝐔𝐄́ 𝐄𝐒𝐓𝐀́ 𝐌𝐀𝐋 𝐀𝐐𝐔𝐈́❓ | 𝐃𝐞𝐬𝐚𝐟𝐢́𝐨 𝐂𝐢𝐬𝐜𝐨

Todo parecía bastante simple.

Había que conectar dos switches mediante dos enlaces GigabitEthernet y agruparlos en un EtherChannel.

La idea era tener mayor capacidad entre ambos switches y, al mismo tiempo, evitar depender de un único enlace físico.

Se realizó la configuración.

Los cables estaban conectados.

Las interfaces estaban up.

Los puertos estaban configurados como trunk.

Pero había un pequeño problema:

𝐄𝐥 𝐄𝐭𝐡𝐞𝐫𝐂𝐡𝐚𝐧𝐧𝐞𝐥 𝐬𝐢𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐞 𝐧𝐨 𝐬𝐞 𝐟𝐨𝐫𝐦𝐚𝐛𝐚 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐚𝐦𝐞𝐧𝐭𝐞.

En SW1 encontramos:

interface range GigabitEthernet0/1 - 2
switchport mode trunk
channel-group 1 mode active
!
interface Port-channel1
switchport mode trunk

Hasta aquí podría parecer correcto.

Ahora revisamos SW2:

interface range GigabitEthernet0/1 - 2
switchport mode trunk
channel-group 1 mode on
!
interface Port-channel1
switchport mode trunk

A primera vista tampoco parece haber nada demasiado extraño.

Los mismos puertos.

El mismo channel-group 1.

Ambos lados configurados como trunk.

Las interfaces físicas están activas.

Entonces…

𝐏𝐨𝐫 𝐪𝐮𝐞́ 𝐧𝐨 𝐬𝐞 𝐟𝐨𝐫𝐦𝐚 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐚𝐦𝐞𝐧𝐭𝐞 𝐞𝐥 𝐄𝐭𝐡𝐞𝐫𝐂𝐡𝐚𝐧𝐧𝐞𝐥❓

Hay un detalle pequeño en la configuración que cambia completamente la forma en que ambos switches intentan construir la agregación.

💡 Pista: no te fijes solamente en el número del channel-group.

Mira con atención cómo está configurado cada extremo.

Ahora imagina que estás conectado por consola y tienes que diagnosticarlo sin cambiar nada todavía.

¿Qué comando ejecutarías primero?

Y la pregunta más importante:

𝐄𝐧𝐜𝐨𝐧𝐭𝐫𝐚𝐬𝐭𝐞 𝐥𝐚 𝐟𝐚𝐥𝐥𝐚❓

Déjame tu diagnóstico en los comentarios, pero intenta explicar por qué esa configuración provoca el problema.

Después publicamos la solución y vemos cómo debería quedar configurado correctamente en ambos switches. 👇

𝐓𝐄𝐋𝐍𝐄𝐓 𝐅𝐔𝐍𝐂𝐈𝐎𝐍𝐀… 𝐏𝐄𝐑𝐎 ¿𝐇𝐀𝐒 𝐕𝐈𝐒𝐓𝐎 𝐋𝐎 𝐐𝐔𝐄 𝐕𝐈𝐀𝐉𝐀 𝐏𝐎𝐑 𝐋𝐀 𝐑𝐄𝐃❓

Telnet todavía aparece en algunos laboratorios y equipos antiguos. Permite conectarnos remotamente a un switch o router Cisco, autenticarnos y administrarlo desde la CLI.

El problema no es que Telnet no funcione.

El problema es que la sesión no está cifrada.

Pensemos en un laboratorio sencillo:

💻 PC Administrador: 192.168.10.20
🔀 Switch Cisco: 192.168.10.10
🔌 Telnet: TCP/23

Desde el PC iniciamos la conexión:

telnet 192.168.10.10

Ingresamos nuestras credenciales y comenzamos a trabajar normalmente.

Ahora hacemos algo distinto.

Configuramos un SPAN/Port Mirroring en nuestro laboratorio y capturamos esa comunicación con Wireshark.

Ahí cambia completamente la perspectiva.

Telnet transporta el contenido de la sesión sin cifrado. Si alguien consigue observar ese tráfico, potencialmente puede reconstruir información de la sesión, incluyendo datos de autenticación, comandos ejecutados y respuestas entregadas por el dispositivo.

Por ejemplo, durante una sesión administrativa podrían circular comandos como:

show running-config
show ip interface brief
show vlan brief
show ip route

Esto también aclara algo importante sobre Wireshark:

No basta con instalar Wireshark en cualquier PC conectado al mismo switch para ver automáticamente el tráfico unicast de otros equipos.

En una red conmutada normalmente necesitaremos estar en el camino del tráfico o utilizar mecanismos autorizados de captura, como SPAN/Port Mirroring, un TAP de red u otra arquitectura de monitoreo.

¿Y si repetimos exactamente la prueba con SSH?

Wireshark seguirá viendo la comunicación: direcciones IP, TCP, puertos, establecimiento de conexiones, tamaños de paquetes, tiempos y otros metadatos.

Pero existe una diferencia fundamental:

𝐓𝐄𝐋𝐍𝐄𝐓 → 𝐜𝐨𝐧𝐭𝐞𝐧𝐢𝐝𝐨 𝐝𝐞 𝐥𝐚 𝐬𝐞𝐬𝐢𝐨́𝐧 𝐬𝐢𝐧 𝐜𝐢𝐟𝐫𝐚𝐫

𝐒𝐒𝐇 → 𝐜𝐨𝐧𝐭𝐞𝐧𝐢𝐝𝐨 𝐝𝐞 𝐥𝐚 𝐬𝐞𝐬𝐢𝐨́𝐧 𝐜𝐢𝐟𝐫𝐚𝐝𝐨

Por eso, en un equipo Cisco, una configuración básica debería restringir las líneas VTY a SSH:

line vty 0 4
login local
transport input ssh

Por supuesto, el dispositivo debe tener SSH correctamente habilitado y configurado.

Este es uno de esos conceptos que se entiende mucho mejor cuando lo ves en un laboratorio que cuando simplemente lees:

“Telnet no es seguro”.

Captura una sesión Telnet propia, analiza qué ocurre y después repite el ejercicio utilizando SSH.

La diferencia en Wireshark explica por sí sola por qué Telnet no debería utilizarse para administrar infraestructura de red en producción.

⚠️ Siempre en equipos propios, laboratorios o infraestructura donde tengas autorización para realizar capturas.

𝐂𝐨́𝐦𝐨 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐫 𝐒𝐒𝐇 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐚𝐦𝐞𝐧𝐭𝐞 𝐞𝐧 𝐮𝐧 𝐫𝐨𝐮𝐭𝐞𝐫 𝐂𝐢𝐬𝐜𝐨 𝐲 𝐪𝐮𝐞́ 𝐨𝐜𝐮𝐫𝐫𝐞 𝐫𝐞𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐝𝐞𝐭𝐫𝐚́𝐬 𝐝𝐞 𝐥𝐨𝐬 𝐜𝐨𝐦𝐚𝐧𝐝𝐨𝐬❓

Configurar SSH no es simplemente copiar una lista de comandos. Para que la administración remota funcione correctamente necesitamos conectividad IP, autenticación y un canal seguro de administración.

Tomemos un ejemplo sencillo:

* Admin-PC: 192.168.10.10/24
* Router R1: 192.168.10.1/24
* SSH: TCP/22

Ambos dispositivos pertenecen a la red 192.168.10.0/24, por lo que el PC puede alcanzar directamente al router a través del switch.

Lo primero que haría antes de pensar en SSH es comprobar la conectividad:

ping 192.168.10.1

Si no tenemos conectividad IP, SSH tampoco funcionará.

En R1 configuramos la interfaz:

interface g0/0
ip address 192.168.10.1 255.255.255.0
no shutdown

Ahora preparamos el router para SSH:

hostname R1
ip domain-name lab.local

El hostname y el nombre de dominio forman parte de los parámetros que IOS utiliza al generar las claves RSA del dispositivo.

Creamos un usuario local:

username admin privilege 15 secret

Utilizar secret permite que el secreto se almacene mediante un hash, en lugar de quedar directamente legible en la configuración. El mecanismo exacto utilizado dependerá de la versión y configuración de IOS.

Generamos las claves RSA:

crypto key generate rsa modulus 2048

Estas claves permiten identificar criptográficamente al servidor SSH y participan en el establecimiento seguro de la sesión.

Luego habilitamos SSH versión 2:

ip ssh version 2

Ahora viene una parte fundamental: las líneas VTY.

line vty 0 4
login local
transport input ssh

¿Qué estamos haciendo aquí?

login local indica que la autenticación utilizará la base de usuarios local del router.

transport input ssh permite SSH como protocolo de acceso remoto en esas líneas VTY y evita dejar Telnet habilitado innecesariamente.

Desde el PC podemos conectarnos con:

ssh [email protected]

En ese momento el cliente inicia una conexión TCP hacia el puerto 22 de R1. A partir de ahí comienza la negociación SSH: se establecen los parámetros criptográficos de la sesión, el cliente puede verificar la identidad del servidor y posteriormente se realiza la autenticación del usuario.

Si todo está correcto, terminaremos dentro del CLI del router:

R1 #

Pero aquí aparece una parte interesante para troubleshooting.

Si:

❌ ping 192.168.10.1 no responde → primero revisaría conectividad IP, interfaz, direccionamiento, VLAN, cableado o rutas según la topología.

Si:

✅ ping 192.168.10.1 responde
❌ SSH no conecta

entonces el problema probablemente ya no está en la conectividad IP básica. Tendríamos que revisar el servicio SSH, las claves RSA, las líneas VTY, transport input, autenticación, ACL y cualquier filtro que pueda afectar TCP/22.

Esa separación es muy útil cuando estamos diagnosticando una red.

𝐘 𝐩𝐨𝐫 𝐪𝐮𝐞́ 𝐒𝐒𝐇 𝐞𝐧 𝐥𝐮𝐠𝐚𝐫 𝐝𝐞 𝐓𝐞𝐥𝐧𝐞𝐭?

Porque SSH proporciona confidencialidad e integridad para la sesión de administración, mientras que Telnet no ofrece esa protección criptográfica y puede exponer información sensible de la sesión a alguien capaz de observar el tráfico.

En una red real todavía podemos mejorar bastante esta configuración: utilizar una VLAN o red exclusiva de administración, limitar mediante ACL qué equipos pueden acceder a las VTY, implementar AAA con TACACS+ o RADIUS, controlar privilegios, registrar accesos y proteger el plano de gestión.

Al final, aprender SSH no debería ser memorizar:

crypto key generate rsa

La lógica completa es mucho más importante:

Conectividad IP → identidad del dispositivo → claves → autenticación → VTY → SSH → control de acceso → administración segura.

Cuando entiendes esa secuencia, también resulta mucho más fácil descubrir por qué SSH no funciona cuando algo está mal configurado.

𝐓𝐞 𝐜𝐮𝐞𝐬𝐭𝐚 𝐞𝐧𝐭𝐞𝐧𝐝𝐞𝐫 𝐒𝐮𝐛𝐫𝐞𝐝𝐞𝐬 𝐲 𝐕𝐋𝐒𝐌❓

Acabo de publicar un video donde intento explicar este tema de una forma un poco distinta, porque muchas veces nos enseñan a sacar la máscara, calcular hosts y aplicar fórmulas, pero no nos explican bien por qué estamos haciendo esos cálculos.

🎥 𝐕𝐢𝐝𝐞𝐨 𝐜𝐨𝐦𝐩𝐥𝐞𝐭𝐨:

https://youtu.be/BToNs40pGt4?si=rxoG3i42l-Zi5A1o

Por ejemplo, si tenemos una red 192.168.10.0/24 y necesitamos crear un segmento para 50 equipos, ¿qué máscara deberíamos utilizar?

Una /27 (255.255.255.224) no nos sirve, porque tenemos 32 direcciones y solo 30 son utilizables para hosts.

En cambio, una /26 (255.255.255.192) nos entrega 64 direcciones, de las cuales 62 podemos utilizar para hosts.

Entonces tendríamos:

Red: 192.168.10.0/26
Hosts: 192.168.10.1 hasta 192.168.10.62
Broadcast: 192.168.10.63

Y desde 192.168.10.64 podemos comenzar a asignar la siguiente subred.

Ahora, si esa segunda red necesita solamente 25 equipos, no tendría mucho sentido asignarle otra /26. Podemos utilizar una /27, que permite hasta 30 hosts.

Eso es justamente lo interesante de VLSM: no se trata solamente de hacer cálculos, sino de asignar el espacio de direccionamiento de acuerdo con lo que realmente necesita cada segmento.

Como referencia:

/25 → 126 hosts
/26 → 62 hosts
/27 → 30 hosts
/28 → 14 hosts

Pero más que memorizar esos números, lo importante es entender qué hay detrás de ellos.

¿Cuántos hosts necesito? ¿Qué máscara me sirve? ¿Dónde termina la subred? ¿Cuál es el broadcast? ¿Dónde comienza la siguiente sin solaparse?

De eso trata el video. Lo hice pensando especialmente en quienes están comenzando con redes, Cisco o CCNA y sienten que subnetting se les hace más complicado de lo necesario.

Si estás estudiando estos temas, espero que te sirva 👍

Y les dejo una para practicar:

Si necesitas una red para 100 hosts, ¿usarías /25, /26 o /27?

Los leo 👇

¿El subnetting es difícil? Aprende este truco y no vuelvas a fallar 🎓 Curso Configuración de Switches y Router Cisco — Desde Cero a Ava...

𝐕𝐋𝐒𝐌: 𝐜𝐮𝐚𝐧𝐝𝐨 𝐝𝐢𝐯𝐢𝐝𝐢𝐫 𝐮𝐧𝐚 𝐫𝐞𝐝 /𝟐𝟒 𝐞𝐧 𝐩𝐚𝐫𝐭𝐞𝐬 𝐢𝐠𝐮𝐚𝐥𝐞𝐬 𝐞𝐬 𝐝𝐞𝐬𝐩𝐞𝐫𝐝𝐢𝐜𝐢𝐚𝐫 𝐝𝐢𝐫𝐞𝐜𝐜𝐢𝐨𝐧𝐞𝐬

Supongamos que te asignan:

192.168.10.0/24

Y necesitas direccionar cuatro segmentos:

LAN A → 100 hosts
LAN B → 50 hosts
LAN C → 20 hosts
LAN D → 10 hosts

Un error típico sería asignar subredes del mismo tamaño a todas las LAN.

𝐂𝐨𝐧 𝐕𝐋𝐒𝐌 (𝐕𝐚𝐫𝐢𝐚𝐛𝐥𝐞 𝐋𝐞𝐧𝐠𝐭𝐡 𝐒𝐮𝐛𝐧𝐞𝐭 𝐌𝐚𝐬𝐤) 𝐩𝐨𝐝𝐞𝐦𝐨𝐬 𝐮𝐭𝐢𝐥𝐢𝐳𝐚𝐫 𝐝𝐢𝐟𝐞𝐫𝐞𝐧𝐭𝐞𝐬 𝐩𝐫𝐞𝐟𝐢𝐣𝐨𝐬 𝐝𝐞𝐧𝐭𝐫𝐨 𝐝𝐞 𝐥𝐚 𝐦𝐢𝐬𝐦𝐚 𝐫𝐞𝐝, 𝐚𝐣𝐮𝐬𝐭𝐚𝐧𝐝𝐨 𝐜𝐚𝐝𝐚 𝐬𝐮𝐛𝐫𝐞𝐝 𝐚 𝐬𝐮 𝐧𝐞𝐜𝐞𝐬𝐢𝐝𝐚𝐝 𝐫𝐞𝐚𝐥.

La regla técnica es:

2ⁿ − 2 ≥ cantidad de hosts requeridos

Donde n corresponde a los bits disponibles para hosts.

Entonces diseñamos desde la necesidad más grande hacia la más pequeña:

Segmento Hosts Prefijo Máscara Rango utilizable
LAN A 100 /25 255.255.255.128 192.168.10.1 – 126
LAN B 50 /26 255.255.255.192 192.168.10.129 – 190
LAN C 20 /27 255.255.255.224 192.168.10.193 – 222
LAN D 10 /28 255.255.255.240 192.168.10.225 – 238

¿Y qué ocurrió con el /24 original?

🔹 192.168.10.0/25 → 128 direcciones
🔹 192.168.10.128/26 → 64 direcciones
🔹 192.168.10.192/27 → 32 direcciones
🔹 192.168.10.224/28 → 16 direcciones

Todavía queda disponible:

192.168.10.240/28

Aquí aparece un concepto importante: VLSM no crea direcciones IP. Lo que hace es permitir que distribuyamos el espacio disponible con mayor granularidad.

𝐐𝐮𝐞́ 𝐝𝐞𝐛𝐞 𝐝𝐨𝐦𝐢𝐧𝐚𝐫 𝐫𝐞𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐮𝐧 𝐢𝐧𝐠𝐞𝐧𝐢𝐞𝐫𝐨 𝐝𝐞 𝐫𝐞𝐝𝐞𝐬❓

No basta con saber que un /26 tiene 64 direcciones.

Debes ser capaz de determinar rápidamente:

Network ID → primer host → último host → broadcast → siguiente subred

Por ejemplo:

192.168.10.192/27

Bloque = 32 direcciones

Network ID: 192.168.10.192
Primer host: 192.168.10.193
Último host: 192.168.10.222
Broadcast: 192.168.10.223
Siguiente bloque: 192.168.10.224

Y aquí viene una buena pregunta para practicar 👇

🔥 Te entregan 10.20.30.0/24 y necesitas crear redes para:

60, 30, 12 y 6 hosts.

¿Qué prefijo asignarías a cada una y cuáles serían sus Network ID?

No uses una calculadora de subredes. Intenta resolverlo primero en papel.

𝐍𝐨 𝐭𝐨𝐝𝐨𝐬 𝐥𝐨𝐬 𝐩𝐮𝐞𝐫𝐭𝐨𝐬 𝐝𝐞 𝐮𝐧 𝐞𝐪𝐮𝐢𝐩𝐨 𝐝𝐞 𝐫𝐞𝐝 𝐬𝐢𝐫𝐯𝐞𝐧 𝐩𝐚𝐫𝐚 ❞𝐜𝐨𝐧𝐞𝐜𝐭𝐚𝐫 𝐈𝐧𝐭𝐞𝐫𝐧𝐞𝐭❞. Y aunque algunos se parezcan, pueden hacer cosas completamente distintas.

Cuando uno empieza en redes es fácil mirar un router o un switch y pensar: “Bueno… son puertos. Conecto el cable y listo.”

Hasta que aparecen nombres como 𝐂𝐨𝐧𝐬𝐨𝐥𝐞, 𝐒𝐅𝐏+, 𝐐𝐒𝐅𝐏𝟐𝟖, 𝐏𝐨𝐄 𝐨 𝐒𝐞𝐫𝐢𝐚𝐥.

Ahí empieza lo interesante.

Un 𝐑𝐉𝟒𝟓 𝐄𝐭𝐡𝐞𝐫𝐧𝐞𝐭 puede conectar un PC, un switch, un router o un punto de acceso. Si además el puerto soporta PoE, por ese mismo cable pueden viajar datos y alimentación eléctrica, permitiendo alimentar dispositivos como cámaras IP, teléfonos IP o access points.

El 𝐩𝐮𝐞𝐫𝐭𝐨 𝐂𝐨𝐧𝐬𝐨𝐥𝐞, en cambio, tiene otro propósito. No está pensado para transportar el tráfico normal de los usuarios: permite acceder localmente a la CLI del dispositivo para configurarlo o recuperarlo cuando incluso la administración por red no está disponible.

Después aparecen los transceptores.

𝐒𝐅𝐏 se utiliza habitualmente para enlaces de hasta 1 Gbps, mientras que SFP+ permite trabajar típicamente a 10 Gbps.

¿Necesitamos todavía más capacidad?

𝐐𝐒𝐅𝐏+ permite enlaces de 40 Gbps, tradicionalmente mediante cuatro canales de 10 Gbps, y 𝐐𝐒𝐅𝐏𝟐𝟖 lleva esa capacidad a 100 Gbps, típicamente con cuatro canales de 25 Gbps.

Y hay interfaces que hoy vemos menos en instalaciones nuevas, pero que siguen siendo importantes para entender cómo evolucionaron las redes.

Los puertos seriales fueron ampliamente utilizados para enlaces 𝐖𝐀𝐍 punto a punto y protocolos como PPP y HDLC. Si has trabajado con laboratorios Cisco, seguramente los has encontrado más de una vez.

También existen las ranuras de expansión, que permiten agregar módulos al equipo y ampliar sus capacidades sin reemplazar todo el dispositivo.

Lo curioso es que detrás de cada pequeño conector hay una función completamente diferente.

Por eso aprender redes no consiste solamente en memorizar comandos.

También consiste en mirar un equipo y entender qué estás viendo, para qué sirve cada interfaz y qué tipo de comunicación puede pasar por ella.

A primera vista, ¿cuántos de estos puertos reconocerías sin mirar el nombre?