Como parte de mi aprendizaje en ingeniería de redes, diseñé e implementé un mega laboratorio en GNS3 simulando la infraestructura de una empresa ficticia llamada Void Insurance Group.

---

Introducción

El objetivo de este proyecto fue diseñar una arquitectura empresarial realista, priorizando escalabilidad, alta disponibilidad, segmentación y seguridad.

La empresa simulada incluye:

• 1 Sede Central (HQ)
• 4 sucursales de distintos tamaños
• Data Center centralizado
• ISPs con distintos ASN simulando Internet
• PCs con Linux o Windows 7

---

Arquitectura General

La topología fue estructurada bajo un modelo jerárquico:

• En HQ se utiliza una arquitectura Tier 3, con las capas Core, Distribution y Access, más 2 routers WAN. Si un router WAN se cae, el otro continúa funcionando. A su vez, esta sede central se divide en 2 subredes: una zona A, que cuenta con 2 switches de distribución y varios switches de acceso, y una zona B con un switch de distribución y switches de acceso, pensando en el hecho de que la zona B sería más pequeña que la zona A.
• En las sucursales grandes o medianas, como por ejemplo la de La Plata o la de Avellaneda, se usa arquitectura Tier 2 (Collapsed Core) más WAN. El tamaño de la branch determina la cantidad de routers, switches y otros dispositivos en la red.
• En las sucursales pequeñas, como por ejemplo la de Quilmes, se utiliza solo un switch conectado a un router WAN, debido a que hay menor cantidad de dispositivos. Para estos casos se utiliza Router-on-a-Stick (ROAS).
• En todos los casos, el switching de la capa de acceso es segmentado por VLANs.

---

Enrutamiento y WAN

OSPF

Se utilizó OSPF como protocolo de enrutamiento interno, tanto para la red corporativa como para los túneles VPN entre sedes. Para los túneles, se utiliza el tipo point-to-point para evitar tráfico innecesario de OSPF, que para este caso no es necesario. La default gateway la informan los routers WAN del HQ, por lo que todo el tráfico pasa por allí. Por último, las interfaces que conectan a las ISP tienen desactivados los mensajes OSPF para mayor seguridad (passive interface).

BGP

Los routers WAN del HQ intercambian rutas mediante BGP con los routers de los ISPs para que haya conectividad a Internet, no solo desde la sede principal, sino también desde las sucursales que se conectan por IPsec. Además, toda la red de Internet simulada utiliza BGP (eBGP) para intercambiar rutas entre las distintas ISP (cada una con un ASN distinto).

VPN Site-to-Site

Las sucursales se conectan de forma segura al HQ mediante VPN Site-to-Site (túneles GRE over IPsec), ya que la confidencialidad e integridad del tráfico corporativo es fundamental. Se utilizan perfiles IPsec en modo transporte, que permiten encriptar el tráfico con AES, asegurar integridad con SHA-256 y autenticación con una Pre-Shared Key (PSK). Cada router WAN de cada sucursal forma 2 túneles con el HQ.

PAT

Se implementó Port Address Translation (PAT) en el borde WAN del HQ para permitir salida a Internet desde las redes internas. De esta forma, las direcciones IPv4 privadas se traducen a la IP de alguno de los routers WAN del HQ. Por eso, a pesar de que la red interna sea 172.16.0.0/16, los paquetes provenientes del HQ que las ISP simuladas analizan cuentan con la dirección traducida 10.0.0.30 o 10.0.0.34.

Alta Disponibilidad

Los routers WAN del HQ están conectados a 2 ISPs para garantizar alta disponibilidad. Si se cae un ISP, el otro permite mantener la conectividad. Por otro lado, en el HQ y en las sucursales grandes se utiliza HSRP en la capa de distribución. Utilizando una IP virtual, se permite a los usuarios seguir conectados a la red incluso si ocurre una falla en alguno de los switches de distribución.

Debido a toda la configuración de protocolos y servicios, la red puede tardar aproximadamente 5 minutos en alcanzar su funcionamiento normal. El proceso es el siguiente:

1. Se inicializa y sincroniza BGP entre los routers WAN.
2. Se establecen los túneles GRE over IPsec entre las sucursales y la sede central.
3. Se inicializa y converge OSPF entre los routers internos de la empresa.
4. El Spanning Tree Protocol hace que los switches pasen por los estados discarding -> learning -> forwarding.
5. Los dispositivos finales realizan solicitudes DHCP para obtener una dirección IP dinámica.
6. Una vez completados estos procesos, es posible acceder a la red e Internet.

---

Direccionamiento IP

La red interna de la compañía utiliza el rango 172.16.0.0/16, mientras que la WAN utiliza el rango 10.0.0.0/8. Si bien las direcciones privadas no son ruteables en Internet, el acceso externo es posible gracias al uso de NAT (Network Address Translation).

Por otro lado, las conexiones punto a punto entre las ISP y entre la red empresarial y las ISP utilizan máscara /30, optimizando así el uso de direcciones IP.

Teniendo en cuenta los requerimientos de la empresa, la segmentación mediante VLSM queda definida de la siguiente manera:

Segmentación interna del HQ

La sede central (HQ) se subdivide en tres zonas:

• La zona A (mayor densidad de empleados): 172.16.16.0/21
• La zona B: 172.16.24.0/22
• El Core de la red: 172.16.28.0/24

Túneles GRE over IPsec

Los túneles GRE over IPsec tienen reservado el rango 172.16.0.0/24.
Cada enlace utiliza máscara /30, ya que se trata de enlaces punto a punto.

VLANs y asignación de direcciones

Dentro de cada sede (o zona, en el caso del HQ), se realiza una subdivisión adicional mediante VLSM para la creación de VLANs.

• Las VLANs con mayor cantidad de usuarios (por ejemplo, WiFi o Users) reciben subredes con mayor capacidad.
• VLANs con menor densidad (como Voice o Management) utilizan máscaras más restrictivas.

Más allá de la configuración de SVIs o ROAS, la asignación de direcciones IP por VLAN se gestiona principalmente desde el servidor DHCP ubicado en el Data Center.

El servidor DHCP está configurado de forma que:

• Las primeras 8 direcciones de cada subred quedan reservadas para asignaciones estáticas.
• En entornos con HSRP:
  • Las dos primeras direcciones IP se asignan a las SVIs de los switches multicapa.
  • La última dirección utilizable se reserva como Virtual IP (default gateway de los dispositivos).

Capacidad de crecimiento

Cada subred de las sucursales mantiene espacio de direccionamiento sin utilizar, reservado para futuras expansiones.

Además, las subredes 172.16.56.0/22 y 172.16.60.0/23 se encuentran disponibles en caso de que nuevas sucursales deban incorporarse a la red.

---

Switching y Capa 2

La red de la sede principal fue segmentada mediante múltiples VLANs:

• Users
• IT
• Management
• Printers
• VoIP
• WiFi
• Guest

Para las sucursales más pequeñas se utilizan menos VLANs, priorizando que ciertas VLANs como la de Users tengan más direcciones IP disponibles que las demás. Es decir, si tengo un bloque de 64 direcciones, 32 son para la VLAN Users y las 32 que sobran se reparten entre VoIP y Management.

Tecnologías de Capa 2 Implementadas

Los switches multicapa (L3 Switch) de distribución utilizan EtherChannel para aumentar el ancho de banda entre ellos. Esto es importante en casos de tráfico elevado.

También se ajustó Spanning Tree para que el root bridge coincida con el switch que actúa como HSRP activo en cada VLAN. En algunas VLANs un switch puede ser root bridge y HSRP activo, mientras que en otras puede no ser root bridge y a su vez actuar como HSRP pasivo.

Además, se implementó BPDU Guard y PortFast para mayor estabilidad y seguridad en la capa de acceso, siempre habilitados en las interfaces que conectan a los dispositivos de usuario.

Por otro lado, se deshabilitó DTP por cuestiones de seguridad y se configuró VTP para que los switches de distribución controlen la base de datos de VLANs. Los switches de distribución están en modo servidor y los switches de acceso están en modo cliente.

Por último, se aplicaron medidas para prevenir ataques de capa 2:

• Port Security (Limita qué dispositivos (MAC) pueden conectarse a un puerto del switch).
• DHCP Snooping (Solo permite servidores DHCP confiables y bloquea respuestas falsas).
• Dynamic ARP Inspection (Verifica mensajes ARP para evitar suplantación).

---

Segmentación y Seguridad

Se implementaron ACLs para evitar que cierto tipo de tráfico acceda a determinadas subredes. Por ejemplo, una de las políticas de seguridad de la compañía es que todos los dispositivos deben hacer sus peticiones DNS al servidor interno, sin excepciones.

Por otro lado, se desactivó Telnet en los dispositivos y se implementó acceso remoto mediante SSH, evitando así el uso de consola serial para su configuración y administración. Además, se restringe el acceso por SSH a la red empresarial interna.

---

Servicios de Infraestructura

El Data Center centralizado incluye:

• Un servidor de infraestructura con servicio de DNS interno (usando el servicio dnsmasq). Además, cuenta con servidor DHCP segmentado por VLAN. Cada subred de cada sucursal dispone de su pool de direcciones, su default gateway, dirección de servidor DNS y nombre de dominio.

• Un servidor de servicios SFTP y HTTP utilizando sshd and httpd.

---

Monitoreo de Logs

Se centralizó el monitoreo con Loki + Grafana para la visualización de logs en una Raspberry Pi 4 externa a la red de GNS3, simulando Grafana en la nube.

Los dispositivos envían mediante Syslog los eventos que ocurren a la Raspberry Pi 4. Cada uno envía además su hostname junto al mensaje para que sea más fácil de filtrar en el dashboard de Grafana Loki.

---

Desafíos Técnicos Encontrados

Durante la implementación surgieron múltiples desafíos técnicos:

• Configuración de DHCP para cada VLAN en cada sucursal. Fue importante tener en cuenta los rangos de direcciones IP y reservar la dirección IP del default gateway.
• Encontré problemas al configurar Loki con Grafana y Promtail. Los errores en Promtail hacían que el servidor se llenara de logs y fuera más difícil realizar debugging. El mayor problema fue descubrir que el firewall del servidor bloqueaba datos de Promtail hacia Grafana (a pesar de estar todo en localhost).
• En varias ocasiones OSPF no formaba adyacencias a través de IPsec. Luego de un troubleshooting extenso, descubrí que el problema era que las sucursales no ejecutaban BGP (lo cual era intencional), por lo que agregué una ruta estática y el problema se solucionó.
• Intenté agregar pfSense y otros firewalls como VyOS u OpenWrt, pero el consumo de RAM era muy alto, por lo que debía elegir entre tener un firewall dedicado o más sucursales y servidores.
• Para crear un IP phone utilicé una VM con Alpine Linux e implementé un bridge. De esta manera, se puede conectar una PC al IP phone y este último al switch de acceso, cada uno en su VLAN correspondiente. Hubo dificultades para que el teléfono etiquetara el tráfico VoIP en 802.1Q, pero se resolvió instalando paquetes adicionales.
• Las VPNs IPsec no se establecían debido a rutas faltantes en los ISPs. Es importante tener cuidado con las rutas que se anuncian por BGP.
• Algunas interfaces VLAN en los switches multicapa estaban en estado down/down. Tras revisar la documentación oficial, confirmé que si la VLAN no está asociada a ninguna interfaz física activa, la SVI (Switch Virtual Interface) permanece en ese estado.
• En la parte final del proyecto, decidí cambiar completamente el rango de direcciones IP de cada subred, ya que me di cuenta de que había asignado muy pocas direcciones a las sucursales. Por ejemplo, una sucursal que anteriormente solo podía soportar 32 dispositivos ahora puede soportar 128 dispositivos, además de contar con direcciones IP adicionales reservadas para futuras expansiones.
• En un momento, el servidor se bloqueó y el archivo del laboratorio quedó corrupto. Afortunadamente, contaba con backups periódicos, lo que me permitió continuar rápidamente con el proyecto.

La resolución de estas problemáticas implicó análisis de tablas de enrutamiento, debugging de protocolos, verificación de estados de túneles y pruebas de conectividad usando herramientas como ping o traceroute.

---

Aprendizajes Clave

• Diseño de arquitecturas y segmentación de subredes.
• Implementación de seguridad y alta disponibilidad en redes empresariales.
• Previo a la realización del proyecto, no sabía cómo funcionaban detalladamente ni cómo se configuraban BGP e IPsec.
• Uso de Wireshark en ciertos casos.
• Configuración de servicios como DHCP, DNS y dnsmasq en Linux.
• Troubleshooting mediante ping y traceroute.
• Filtrado y configuración de logeo.

Más allá de la configuración, el mayor aprendizaje fue pensar en términos de arquitectura, resiliencia y operación.

---

Posibles Mejoras Futuras

• Implementación de IPv6.
• Conexiones WAN dual multihomed.
• Automatización de configuraciones (Ansible).
• Implementar DMZ en el servidor services.
• Integración de Active Directory.
• Monitoreo con Prometheus.
• Implementación de políticas más avanzadas de BGP.
• Redundancia en el Data Center.

---

Conclusión

Este laboratorio fue concebido como una simulación realista de infraestructura empresarial, con foco en:

• Escalabilidad
• Seguridad
• Alta disponibilidad
• Control operativo

Si te ha parecido interesante el artículo, puedes ayudarme compartiéndolo en alguna red social como LinkedIn. En caso de encontrar un error o algo para mejorar, no dudes en enviarme un mail o un mensaje. ¡Muchas gracias por leer!