Laboratorio Ruteo IP GNS3

1. Topología

la topología para este laboratorio es la siguiente.

2. Configuración del router-1

Como el router-1 está directamente conectado a la nube el winbox de la máquina virtual lo "encuentra" sin problemas.

Como se ve el router-1 incluso ya tiene una dirección IP. Esto se debe a 2 factores:

1. la nube incluye un servidor DHCP
2. los routers MikroTik vienen configurados por defecto como clientes DHCP.

3. Configuración del router-2

En la topología actual el router-2 no está directamente conectado a la nube por ello no parece en el winbox como routers del "vecindario".

Tenemos 2 alternativas para configurar el router-2 con winbox desde el otro lado de la nube.

Conexión directa

En la lista de arrendamientos del servidor DHCP del router-1 vemos que el router-2 adquirió una dirección IP.

Esto se debe a que, como se explicó anteriormente, los routers MikroTik vienen configurados como clientes DHCP.

Se podría pensar que podemos utilizar esta dirección para conectar el winbox al router-2, pero el winbox está del otro lado de la nube y no tiene como llegar más allá del router-1.

El servicio de winbox "atiende" en el puerto de destino 8291 por lo que deberíamos mapear el mismo desde el router-1 al router-2. El problema es que perderíamos el acceso de winbox al router-1.

La solución propuesta consiste en asignarle otro puerto externo al servicio de winbox del router-2. Para ello creamos una regla NAT en el firewall del router-1

Asignamos el puerto externo 9000 (desde la nube) y lo redireccionamos al puerto 8291 del router-2.

Ahora ya podemos conectarnos al router-2 desde el otro lado de la nube utilizando el socket (dirección IP + puerto)

Si no especificamos el puerto junto a la dirección IP el winbox se conecta al router-1 a través del puerto por defecto (8291).

4. Configuración de las PC

Para que las PC soliciten una configuración al servidor DHCP de su red se las debe configurar como clientes DHCP. Esto se lleva a cabo en la configuración de las PC. En GNS3 basta con un click derecho -> Edit config

descomentamos la línea "dhcp" borrando el símbolo numeral al comienzo de la misma

La próxima vez que inicie esa PC va a solicitar una configuración IP al servidor DHCP

En la consola de la PC podemos ver la configuración que adquirió.

si no aparece al abrir la consola, podemos utilizar el comando show para obtener la información.

Repetir el mismo procedimiento en la PC2

Si por alguna razón el dispositivo no adquirió la configuración IP, del servidor DHCP, se puede solicitar nuevamente con el comando "dhcp"

No se olviden de crear el servidor DHCP en el router-2 para la red de la PC2

5. Rutas

Ya tenemos configuradas todas las interfaces de los routers y todos los dispositivos tiene su correspondiente configuración IP.

Si probamos de hacer un ping desde la PC1 a su puerta de enlace funciona perfectamente

Pero si probamos de hacer un ping desde la PC1 a la PC2 falla

Esto se debe a que, si bien el router-1 conoce al router-2, no conoce las redes que están conectadas al segundo router. Es necesario informar eso al router-1. Esto se lleva a cabo en la sección IP->Routes

vemos que el router automáticamente agrega a la lista de rutas las redes que están directamente conectadas a él. Además la dirección de "todas las redes" que representa a la puerta de enlace (gateway) del router. Los destinos con direcciones desconocidas son enrutadas por ese camino.

Con el botón + agregamos una nueva ruta con destino a la red de la PC2 (ether2 del router-2)

La nueva ruta ahora figura en la lista de rutas del router-1 y tiene una distancia de 1 porque no está directamente conectada, sino que hay un router de por medio.

ahora si funciona el ping de PC1 a PC2

También tenemos conectividad desde la PC2 a la WAN

6. Tabla de rutas del host

Al igual que en un router en los host también existe una tabla de ruteo. Tomemos por ejemplo el sistema operativo base de la máquina virtual (linux Lite). Con el comando

    ip route

o

    route -n

se puede ver la lista de rutas del host

En la última entrada se puede ver la ruta a la nube de GNS3 a través de la interfaz bridge virtual (virbr0).

Podemos agregar una ruta estática hacia la red de la PC2 del GNS3, de esta manera el host (linux lite) sabrá que, por más que la dirección destino no está en su propia red, no debe enviar el paquete al gateway, sino que utilizar para ello la ruta predefinida.
El comando es el siguiente:

    sudo ip route add 172.16.0.0/24 via 192.168.122.141 dev virbr0

• Se debe anteponer sudo para ejecutar el comando como superusuario ya que el usuario convencional no tiene los privilegios para editar la tabla de rutas. La contraseña es "com2" (sin comillas).
• route es el comando para administrar la tabla de rutas. Lo que sigue son los parámetros.
• add 172.16.0.0/24 indica el destino que quiero agregar.
• via 192.168.122.141 es el próximo paso para llegar al destino. (por dónde tengo que ir)
• dev virbr0 indica por qué interfaz del host local debo salir. En nuestro caso el bridge virtual que crea el GNS3 para vincularse con el host (linux lite)
  

La nueva ruta ahora aparece en la tabla de rutas.

Ahora podemos llegar directamente desde el host hasta la PC2 en GNS3

Con esta nueva ruta también podemos acceder directamente al router-2 si utilizamos como destino la dirección IP de la interfaz conectada a la ruta recién establecida. Recordemos que un router tiene una dirección IP por cada red a la que se conecta. En este caso la dirección que establecimos en la configuración del router-2 es 172.16.0.1.

7. Preguntas

1. En este laboratorio no se definió una ruta desde el router-2 a la red de la PC1, entonces ¿cómo podían volver las respuestas de las consultas ICMP (ping) de la PC2 a la PC1?
2. ¿Por qué no hace falta establecer una regla NAT de masquerade en el router-2?
3. ¿Que debería hacer para poder acceder directamente desde Linux Lite a la interfaz ether1 del router-2?