eClassVirtual

𝐕𝐏𝐍 𝐞𝐧 𝐂𝐢𝐬𝐜𝐨: 𝐥𝐨 𝐪𝐮𝐞 𝐫𝐞𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐧𝐞𝐜𝐞𝐬𝐢𝐭𝐚𝐬 𝐬𝐚𝐛𝐞𝐫 𝐩𝐚𝐫𝐚 𝐂𝐂𝐍𝐀

Cuando estudias VPN para CCNA, no necesitas comenzar memorizando decenas de comandos.

Primero debes entender qué ocurre con el tráfico.

Imagina este escenario:

🏢 SEDE A
192.168.10.0/24
⬇️
Router Cisco
⬇️
🌐 Internet
⬇️
Router Cisco
⬇️
🏢 SEDE B
192.168.20.0/24

La empresa necesita comunicar ambas redes utilizando Internet.

El problema es evidente:

⚠️ Internet es una red pública y no confiable.

La solución puede ser una:

𝐕𝐏𝐍 𝐒𝐢𝐭𝐞-𝐭𝐨-𝐒𝐢𝐭𝐞

Los routers establecen un túnel VPN que permite proteger la comunicación entre ambas sedes.

¿Dónde entra IPsec?

IPsec proporciona mecanismos para proteger el tráfico IP mediante:

🔒 Confidencialidad → evita que terceros puedan leer los datos.

🛡️ Integridad → permite detectar modificaciones durante el tránsito.

🔑 Autenticación → ayuda a verificar la identidad de los extremos.

Ahora una pregunta típica de concepto:

¿Qué diferencia existe entre estas VPN?

🏢 Site-to-Site VPN
Conecta redes completas.

Ejemplo:

192.168.10.0/24 ↔ 192.168.20.0/24

💻 Remote-Access VPN
Permite que un usuario remoto se conecte de forma segura a la red de una organización.

Ejemplo:

Notebook → Internet → VPN → Red corporativa

📌 Para CCNA, más importante que memorizar una configuración completa de IKE/IPsec es comprender:

• Qué problema resuelve una VPN
• Site-to-Site vs Remote Access
• Qué función cumple IPsec
• Por qué se utiliza cifrado
• Qué significa establecer un túnel sobre una red no confiable

💡 En redes no basta con memorizar comandos.

Cuando entiendes el flujo del tráfico, los comandos comienzan a tener sentido.

𝐐𝐮𝐢𝐞𝐫𝐞𝐬 𝐩𝐫𝐚𝐜𝐭𝐢𝐜𝐚𝐫 𝐂𝐢𝐬𝐜𝐨 𝐲 𝐅𝐨𝐫𝐭𝐢𝐧𝐞𝐭 𝐬𝐢𝐧 𝐭𝐞𝐧𝐞𝐫 𝐮𝐧 𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐨𝐫𝐢𝐨 𝐟𝐢́𝐬𝐢𝐜𝐨❓

Una muy buena alternativa es combinar VMware Workstation Pro + GNS3 + máquinas virtuales para construir un laboratorio de redes y ciberseguridad directamente en tu PC.

La idea es bastante simple:

VMware Workstation Pro nos permite ejecutar máquinas virtuales que actuarán como servidores, estaciones de trabajo o equipos de administración.

GNS3 será el encargado de construir la topología de red y emular o virtualizar los dispositivos de networking.

Y al integrar ambos mundos podemos crear escenarios mucho más cercanos a una red real.

Por ejemplo:

💻 Windows / Linux VM
↓
🔀 Switch / Router Cisco
↓
🔥 FortiGate
↓
🌐 Internet o una segunda red

¿Qué podríamos practicar con algo así?

🔹 VLAN y segmentación de redes
🔹 Routing estático y dinámico
🔹 DHCP y DNS
🔹 NAT/PAT en Cisco
🔹 ACL en Cisco
🔹 Políticas de firewall en FortiGate
🔹 NAT en FortiGate
🔹 Inter-VLAN Routing
🔹 Troubleshooting con ping, traceroute y Wireshark
🔹 Escenarios LAN → Firewall → Internet

Incluso podemos crear algo más interesante:

PC Usuario → Switch Cisco → Router Cisco → FortiGate → Servidor

Después provocamos problemas intencionalmente.

❌ Una VLAN incorrecta
❌ Una ruta que falta
❌ Una ACL bloqueando tráfico
❌ Una política de FortiGate mal configurada
❌ Una configuración NAT incorrecta

Y ahí comienza el verdadero aprendizaje: diagnosticar por qué la comunicación no funciona y encontrar exactamente dónde está la falla.

Eso cambia completamente la forma de estudiar redes.

Ya no se trata solamente de memorizar comandos.

En Cisco, por ejemplo:

* show ip route
* show vlan brief
* show interfaces trunk
* show access-lists

Y en FortiGate:

* get router info
* routing-table all
* show firewall policy
* diagnose sniffer
* packet any
* diagnose debug flow

La clave es aprender qué comando utilizar, qué información buscar y cómo seguir el flujo de un paquete desde el origen hasta el destino para encontrar dónde se produce el problema.

🧠 Porque redes y ciberseguridad se aprenden mucho mejor cuando puedes construir, configurar, romper, diagnosticar y volver a configurar.

👇 ¿Qué laboratorio montarías primero: Cisco, FortiGate o ambos integrados?

𝐐𝐮𝐞́ 𝐩𝐚𝐬𝐚 𝐫𝐞𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐞𝐧 𝐥𝐚 𝐫𝐞𝐝 𝐜𝐮𝐚𝐧𝐝𝐨 𝐩𝐫𝐞𝐬𝐢𝐨𝐧𝐚𝐬 𝐏𝐋𝐀𝐘 𝐞𝐧 𝐒𝐩𝐨𝐭𝐢𝐟𝐲❓

Parece algo simple. Buscas una canción, presionas PLAY y en uno o dos segundos ya está sonando.

Pero desde el punto de vista de redes IP, detrás ocurre bastante.

El dispositivo primero debe ubicar los servicios de Spotify mediante DNS y establecer las conexiones necesarias a través de Internet. Ahí ya tenemos IP, routing, TCP y conexiones cifradas con TLS.

Después comienza algo interesante: Spotify no espera descargar toda la canción.

Empieza a recibir el audio y guarda una parte por adelantado en un buffer.

Más o menos así:

𝐏𝐋𝐀𝐘 ▶ → 𝐃𝐍𝐒 → 𝐈𝐧𝐭𝐞𝐫𝐧𝐞𝐭 → 𝐬𝐞𝐫𝐯𝐢𝐝𝐨𝐫𝐞𝐬/𝐜𝐚𝐜𝐡𝐞́ → 𝐛𝐮𝐟𝐟𝐞𝐫 → 𝐚𝐮𝐝𝐢𝐨

Ese buffer es fundamental.

Supongamos que durante algunos segundos tu conexión baja de rendimiento o aumenta la latencia. La canción no necesariamente se corta, porque el reproductor todavía tiene audio disponible en el buffer.

También hay un detalle que a veces se confunde:

tener una conexión de 500 Mbps no significa que Spotify necesite 500 Mbps.

El audio comprimido requiere una fracción de ese ancho de banda. Lo importante es que la red pueda entregar los datos con suficiente rapidez para mantener alimentado el buffer.

Y después está el problema de escala.

Spotify tiene millones de usuarios reproduciendo contenido al mismo tiempo. No tendría sentido atender todas esas solicitudes desde un único lugar.

Por eso entran conceptos conocidos para cualquiera que trabaje en redes:

𝐢𝐧𝐟𝐫𝐚𝐞𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐚 𝐝𝐢𝐬𝐭𝐫𝐢𝐛𝐮𝐢𝐝𝐚, 𝐜𝐚𝐜𝐡𝐞́, 𝐃𝐍𝐒, 𝐫𝐨𝐮𝐭𝐢𝐧𝐠, 𝐓𝐂𝐏/𝐈𝐏, 𝐓𝐋𝐒, 𝐜𝐨𝐦𝐩𝐫𝐞𝐬𝐢𝐨́𝐧 𝐲 𝐛𝐮𝐟𝐟𝐞𝐫𝐢𝐧𝐠.

Al final, Spotify funciona sobre Internet, una red best effort donde la latencia cambia, puede existir congestión y el throughput no siempre es constante.

Lo interesante es que todo está diseñado para que nosotros simplemente escuchemos:

🎵 PLAY… y música.

Y detrás, bastante ingeniería de redes.

¿Ya sabías todo esto de cómo funciona Spotify por detrás?

Te leo en los comentarios. 👇

𝟏𝟎 𝐜𝐨𝐦𝐚𝐧𝐝𝐨𝐬 𝐂𝐢𝐬𝐜𝐨 𝐩𝐚𝐫𝐚 𝐭𝐫𝐨𝐮𝐛𝐥𝐞𝐬𝐡𝐨𝐨𝐭𝐢𝐧𝐠 𝐪𝐮𝐞 𝐝𝐞𝐛𝐞𝐫𝐢́𝐚𝐬 𝐜𝐨𝐧𝐨𝐜𝐞𝐫

Cuando una red falla, no se trata de ejecutar comandos al azar.

Cada comando debería responder una pregunta.

1️⃣ show interfaces status
👉 ¿El puerto está conectado? ¿Qué VLAN, velocidad y dúplex tiene?

2️⃣ show interfaces counters errors
👉 ¿Hay CRC u otros errores que indiquen un problema en el enlace?

3️⃣ show mac address-table
👉 ¿Por qué puerto está aprendiendo el switch una determinada MAC?

4️⃣ show ip arp
👉 ¿Qué dirección MAC está asociada a una IPv4 conocida por el equipo?

5️⃣ show cdp neighbors detail
👉 ¿Qué dispositivo Cisco está conectado al otro extremo?

6️⃣ show lldp neighbors detail
👉 ¿Qué vecino está conectado utilizando LLDP?

7️⃣ show spanning-tree
👉 ¿STP está bloqueando algún enlace? ¿Quién es el Root Bridge?

8️⃣ show etherchannel summary
👉 ¿Los enlaces del EtherChannel están correctamente agrupados?

9️⃣ show ip route
👉 ¿Existe una ruta para llegar a la red de destino?

🔟 show logging
👉 ¿Qué eventos registró el equipo antes o durante la falla?

𝐋𝐥𝐞𝐯𝐞́𝐦𝐨𝐬𝐥𝐨 𝐚 𝐮𝐧 𝐜𝐚𝐬𝐨 𝐫𝐞𝐚𝐥

Un usuario llama y dice:

“Mi PC está conectada, pero no tengo red.”

En lugar de empezar a cambiar configuraciones, podemos seguir una secuencia:

show interfaces status
→ ¿El puerto aparece connected?

show interfaces counters errors
→ ¿Hay errores físicos o CRC?

show mac address-table interface Gi1/0/10
→ ¿El switch está aprendiendo la MAC del PC?

show ip arp
→ Desde el dispositivo de Capa 3 correspondiente, ¿tenemos una asociación IP–MAC del host?

show spanning-tree interface Gi1/0/10
→ ¿El puerto está en estado forwarding?

Si todo eso está correcto, seguimos avanzando hacia VLAN, gateway, routing, ACL y servicios, según el escenario.

💡 Eso es troubleshooting: ir descartando posibles causas siguiendo una lógica, no ejecutar comandos al azar.

Capa física → Capa 2 → Capa 3 → Servicios

Puedes conocer 100 comandos Cisco, pero lo realmente importante es saber cuál ejecutar, qué buscar en la salida y qué comprobar después.

𝐂𝐮𝐚́𝐧𝐭𝐨 𝐭𝐢𝐞𝐦𝐩𝐨 𝐩𝐞𝐫𝐦𝐚𝐧𝐞𝐜𝐞 𝐮𝐧𝐚 𝐃𝐢𝐫𝐞𝐜𝐜𝐢𝐨́𝐧 𝐌𝐀𝐂 𝐞𝐧 𝐮𝐧 𝐬𝐰𝐢𝐭𝐜𝐡 𝐂𝐢𝐬𝐜𝐨❓

En un switch Cisco, una dirección MAC aprendida dinámicamente permanece normalmente 300 segundos (5 minutos) en la tabla MAC si el switch deja de recibir tráfico desde esa MAC.

Puedes comprobarlo con:

show mac address-table aging-time

Pero ojo 👀: cuando un equipo es reemplazado y la misma dirección IP pasa a utilizar una MAC diferente, pueden aparecer problemas de conectividad que no necesariamente están en la tabla MAC del switch.

𝐀𝐪𝐮𝐢́ 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐧𝐞𝐧 𝐝𝐨𝐬 𝐭𝐚𝐛𝐥𝐚𝐬 𝐝𝐢𝐬𝐭𝐢𝐧𝐭𝐚𝐬:

Tabla MAC del switch
Relaciona:

MAC → Puerto

Tabla ARP de equipos de Capa 3
Relaciona:

IP → MAC

Por ejemplo:

Antes:
10.10.10.50 → AA:AA:AA:AA:AA:AA

Cambias el equipo manteniendo la IP:

10.10.10.50 → BB:BB:BB:BB:BB:BB

El switch normalmente aprenderá la nueva MAC cuando reciba tráfico. Sin embargo, un router, switch capa 3 u otro dispositivo podría conservar temporalmente la asociación ARP anterior:

10.10.10.50 → AA:AA:AA:AA:AA:AA ❌

En Cisco, dependiendo del problema, puede ser necesario limpiar la entrada correspondiente para forzar un nuevo aprendizaje.

Por ejemplo:

clear ip arp 10.10.10.50

Luego el dispositivo vuelve a resolver:

10.10.10.50 → BB:BB:BB:BB:BB:BB ✅

📌 La clave es no confundir MAC Address Table con ARP.

MAC Table: MAC → Puerto
ARP Table: IP → MAC

Si cambias un host por otro manteniendo la misma IP, muchas veces el problema que necesitas limpiar es ARP, no simplemente la tabla MAC.

𝐬𝐡𝐨𝐰 𝐚𝐫𝐩 𝐯𝐬 𝐬𝐡𝐨𝐰 𝐦𝐚𝐜 𝐚𝐝𝐝𝐫𝐞𝐬𝐬-𝐭𝐚𝐛𝐥𝐞: 𝐩𝐚𝐫𝐞𝐜𝐞𝐧 𝐬𝐢𝐦𝐢𝐥𝐚𝐫𝐞𝐬, 𝐩𝐞𝐫𝐨 𝐦𝐮𝐞𝐬𝐭𝐫𝐚𝐧 𝐜𝐨𝐬𝐚𝐬 𝐝𝐢𝐬𝐭𝐢𝐧𝐭𝐚𝐬

Cuando estás diagnosticando conectividad en una red, estos dos comandos pueden darte información muy útil. La clave es entender qué tabla estás consultando.

𝐬𝐡𝐨𝐰 𝐚𝐫𝐩

Muestra la tabla ARP del equipo.

Relaciona:

Dirección IPv4 ↔ Dirección MAC

Ejemplo:

Internet 192.168.10.25 3 0011.2233.4455 ARPA Vlan10

Esto te permite saber:

👉 ¿Qué dirección MAC corresponde a la IP 192.168.10.25?

ARP trabaja en la relación entre Capa 3 y Capa 2.

𝐬𝐡𝐨𝐰 𝐦𝐚𝐜 𝐚𝐝𝐝𝐫𝐞𝐬𝐬-𝐭𝐚𝐛𝐥𝐞

Muestra la tabla MAC o CAM del switch.

Relaciona:

Dirección MAC ↔ VLAN ↔ Puerto

Ejemplo:

Vlan Mac Address Type Ports
10 0011.2233.4455 DYNAMIC Gi1/0/15

Esto responde:

👉 ¿Por qué puerto del switch puedo alcanzar esa MAC?

Es información principalmente de Capa 2.

𝐋𝐨 𝐢𝐧𝐭𝐞𝐫𝐞𝐬𝐚𝐧𝐭𝐞 𝐞𝐬 𝐮𝐬𝐚𝐫 𝐚𝐦𝐛𝐨𝐬 𝐣𝐮𝐧𝐭𝐨𝐬

Supongamos que necesitas encontrar físicamente dónde está conectado el equipo:

192.168.10.25

Primero:

show arp

Encuentras:

192.168.10.25 → 0011.2233.4455

Luego:

show mac address-table address 0011.2233.4455

Encuentras:

0011.2233.4455 → VLAN 10 → Gi1/0/15

🎯 Ahora ya puedes seguir el camino:

IP → MAC → VLAN → Puerto

En resumen

show arp te ayuda a descubrir qué MAC está asociada a una IPv4.

show mac address-table te ayuda a descubrir por qué puerto se alcanza esa MAC.

⚠️ Y una diferencia importante: que una IP aparezca en ARP no significa necesariamente que el dispositivo esté conectado directamente a ese mismo switch. La tabla MAC puede llevarte a un puerto trunk o uplink, y tendrás que seguir buscando en el siguiente switch.

Dos comandos simples, pero juntos son tremendamente útiles para troubleshooting. 🔧🌐

𝐈𝐏𝐯𝟒: 𝐥𝐚 𝐝𝐢𝐫𝐞𝐜𝐜𝐢𝐨́𝐧 𝐪𝐮𝐞 𝐩𝐞𝐫𝐦𝐢𝐭𝐞 𝐞𝐧𝐜𝐨𝐧𝐭𝐫𝐚𝐫 𝐞𝐪𝐮𝐢𝐩𝐨𝐬 𝐞𝐧 𝐮𝐧𝐚 𝐫𝐞𝐝

Cuando conectas un computador, una cámara IP, un servidor o un router a una red, normalmente necesita una dirección IP para poder comunicarse.

Por ejemplo:

192.168.1.25

Una dirección IPv4 tiene 32 bits, divididos en cuatro grupos de 8 bits llamados octetos:

192 . 168 . 1 . 25

Cada octeto puede tener un valor entre 0 y 255.

Pero hay algo importante: una dirección IP no trabaja sola.

Si tenemos:

IP: 192.168.1.25
Máscara: 255.255.255.0

Podemos interpretar, de manera simplificada, que:

🏠 192.168.1 identifica la red
💻 25 identifica al host dentro de esa red

Por eso dos equipos podrían tener:

PC1 → 192.168.1.10
PC2 → 192.168.1.20

y pertenecer a la misma subred.

Ahora imagina:

PC1 → 192.168.1.10
PC2 → 192.168.2.20

Con una máscara /24, están en subredes diferentes. Para comunicarse necesitarán un dispositivo de Capa 3, normalmente un router o un switch multicapa, que pueda enrutar tráfico entre ellas.

💡 Y aquí aparece otro concepto fundamental: el gateway predeterminado.

El gateway es la dirección a la que un host envía el tráfico cuando el destino está fuera de su propia subred.

Por ejemplo:

PC → 192.168.1.25/24
Gateway → 192.168.1.1

Entender bien IP + máscara + red + host + gateway es una de las bases para comprender cómo funcionan las redes IPv4.

Y también para hacer troubleshooting cuando algo no comunica. 🔧

𝐐𝐮𝐞́ 𝐞𝐬 𝐮𝐧 𝐇𝐎𝐒𝐓❓ 𝐌𝐚́𝐬 𝐟𝐚́𝐜𝐢𝐥 𝐝𝐞 𝐥𝐨 𝐪𝐮𝐞 𝐩𝐚𝐫𝐞𝐜𝐞

Estás conectado al Wi-Fi de tu casa.

Tu notebook tiene una IP.
Tu teléfono tiene otra.
La Smart TV tiene otra.
Y quizás hasta la impresora está conectada.

Todos ellos pueden participar como hosts en la red.

¿Pero qué significa realmente?

Un host es un dispositivo que puede actuar como origen o destino de una comunicación de red.

Por ejemplo, abres el navegador desde tu PC y consultas una página alojada en un servidor:

💻 PC → 🌐 Red → 🖥️ Servidor

Tu PC inicia la comunicación y el servidor recibe la solicitud y responde.

Ambos son hosts.

Ahora viene una diferencia importante 👇

Un switch de Capa 2 normalmente no lo consideramos un host cuando está simplemente reenviando las tramas entre dispositivos. Su función principal es actuar como dispositivo intermediario.

Aunque hay un detalle interesante: si ese switch tiene una IP de administración y te conectas a él mediante SSH o HTTPS, en esa comunicación el propio switch está actuando como destino.

📌 Quédate con esta idea:

Host = extremo de la comunicación.

PC, servidores, teléfonos, cámaras IP, impresoras, máquinas virtuales… todos pueden ser hosts.

Parece un concepto básico, pero entenderlo bien ayuda muchísimo cuando después empiezas con direccionamiento IP, VLAN, routing y troubleshooting. 🌐

𝐐𝐮𝐞́ 𝐩𝐮𝐞𝐫𝐭𝐨 𝐓𝐂𝐏 𝐮𝐭𝐢𝐥𝐢𝐳𝐚 𝐏𝐈𝐍𝐆❓

Esta es una pregunta clásica en redes y la respuesta puede sorprender a quienes están comenzando:

👉 PING no utiliza ningún puerto TCP.
👉 Tampoco utiliza puertos UDP.

Entonces, ¿cómo funciona? 🔍

PING utiliza ICMP (Internet Control Message Protocol), un protocolo utilizado principalmente para diagnóstico y notificación de errores en redes IP.

Cuando ejecutamos:

ping 192.168.1.1

normalmente nuestro equipo envía:

📤 ICMP Echo Request — Tipo 8

Y si el destino responde:

📥 ICMP Echo Reply — Tipo 0

¿Por qué PING no necesita puertos?

Los números de puerto pertenecen a protocolos de transporte como TCP y UDP.

Por ejemplo:

🌐 HTTP → TCP 80
🔐 HTTPS → TCP 443
🖥️ SSH → TCP 22
📡 DNS → UDP/TCP 53
🏓 PING → ICMP, sin puerto

⚠️ Pero cuidado con algo muy importante:

𝐒𝐢 𝐮𝐧 𝐞𝐪𝐮𝐢𝐩𝐨 𝐧𝐨 𝐫𝐞𝐬𝐩𝐨𝐧𝐝𝐞 𝐚 𝐏𝐈𝐍𝐆, 𝐧𝐨 𝐬𝐢𝐠𝐧𝐢𝐟𝐢𝐜𝐚 𝐧𝐞𝐜𝐞𝐬𝐚𝐫𝐢𝐚𝐦𝐞𝐧𝐭𝐞 𝐪𝐮𝐞 𝐞𝐬𝐭𝐞́ 𝐜𝐚𝐢́𝐝𝐨.

El servidor, router o firewall puede estar perfectamente operativo y simplemente tener bloqueados o filtrados los mensajes ICMP Echo Request/Echo Reply.

También puede ocurrir lo contrario:

✅ El servidor responde a PING.
❌ Pero el servicio que necesitamos está caído o su puerto está cerrado.

Por ejemplo, un servidor puede responder correctamente a PING y tener TCP 443 cerrado, por lo que su servicio HTTPS no estará disponible.

📌 En troubleshooting recuerda:

PING comprueba alcance IP mediante ICMP.
No comprueba puertos TCP.

Y un PING sin respuesta no demuestra por sí solo que el destino esté caído.

Una diferencia sencilla, pero fundamental cuando estamos diagnosticando problemas de red. 🌐