Capítulo 14: IP Tunneling

Un Túnel IP es básicamente una comunicación entre dos redes diferentes que no tienen un enrutamiento nativo/natural y que normalmente están separadas geográficamente. Necesitan de una red de transporte, como Internet, para formar el túnel.

Se requiere un protocolo de "tunneling", que puede ser seguro o no. Pueden encriptar datos para asegurar la comunicación a través de la red de transporte pública, implementando VPN. También tenemos la opción IPSEC (Ip Security) para añadir seguridad (IPSEC no es parte del JNCIS). Aquí se cubren los túneles GRE y los túneles IP-IP.

TUNELIZACIÓN DE PAQUETES IP

Según entra el paquete al túnel, el protocolo de tunelización encapsula el paquete, incluida la cabecera. Una vez encapsulado, el router lo envía por el siguiente salto para llegar el extremo del router con el que monta el túnel, el que lo desencapsula y lo envía a destino basado en la cabecera original. Un router puede ser encapsulador y desencapsulador al mismo tiempo, obviamente.

Por defecto, solo el tráfico IP es enrutable a través de Internet. Con la tunelización IP podemos usar tráfico de protocolos NO-IP. Sin embargo, Junos no soporta ni AppleTalk ni IPX.

El uso de túneles para crear redundancia está muy aceptado. Un túnel Ip es en realidad una conexión lógica punto-a-punto (P2P) entre dos equipos capaz de funcionar como cualquier otro enlace. Ojo con los protocolos de enrutamiento, pueden preferir los túneles a los enlaces normales, ya que estos ven el destino final a un solo salto y, por lo tanto, con menor coste. Manipulando coste y preferencia podemos modificar el comportamiento. 

TÚNELES GRE (General Routing Encapsulation)

GRE puede transportar otros protocolos de capa 3. Se usan para transportar tanto protocolos IP como los NO-IP. También son usados para el tráfico de IPv6; y en redes MPLS sobre IP aunque esto está fuera del estudio del JNCIS-ENT. 

Para encapsular un paquete GRE en un paquete IP, se añade una cabecera GRE y una IP de cabecera externa que suman 24 bytes más al total del paquete IP. La cabecera IP externa incluye la dirección ip de origen, el punto de entrada al túnel y la direccion ip de destino (el punto de salida del túnel). El paquete interno (también llamado "paquete payload") no es modificado, excepto su TTL, el cual se reduce para asegurarnos de que no tiene un TTL infinito, es decir, que el paquete no tenga un tiempo de vida sin expirar. Los paquetes GRE encapsulados en paquetes IP usan el tipo de protocolo IP número 47.

Aunque GRE fue desarrollado por Cisco, ahora es un estándar que se referencia en la RFC 1702.

TÚNELES IP-IP

El paquete encapsula una cabecera externa antes de la cabecera del paquete IP que lo transporta, añadiendo 20 bytes más al total del paquete. La cabecera externa tiene las ip de origen y destino del túnel. La cabecera interna mantiene las ip de origen y destino sin modificar, pero sí que modifica también como GRE, el TTL, que lo reduce y que tampoco sufre modificación durante el camino.

Como solo puede transportar paquetes IP, es menos usado que GRE, que puede transportar otros.

IP-IP lo podemos ver desarrollado en la RFC 2003.

REQUISITO PARA FORMAR LOS TÚNELES

Debemos definir una interface lógica en cada punto del túnel. 

En túneles GRE definimos la interface como gr-x/y/z. Algunos equipo de Junos los montan sobre interfaces de hardware (PIC) y otros por software. Para ambos la definición de la interface será igual, es decir, el formato gr-x/y/z.

En túneles IP-IP definimos la interfaces como ip-x/y/z.

No todos los equipo de Junos soportan tunelización. Hay que mirar la documentación.

Se pueden montar varios túneles creando diferentes "units" en la interfaces gr- o ip-, pero siempre será un túnel por unit. Se debe especificar siempre las direcciones origen y destino del túnel.

Los túneles deben tener una ruta hacia el otro extremo del túnel. Debe resolver un siguiente salto físico hacia el túnel y no que sea el otro extremo del túnel el siguiente salto. A los equipos intermedios les pasa lo mismo.

Normalmente se configuran los túneles con origen y destino las direcciones loopback en vez las de las direcciones físicas, así proveemos de redundancia cuando tenemos múltiples caminos para llegar a los puntos finales.

Los puntos finales también tiene que tener una ruta para dirigir el tráfico hacia las subredes remotas. Esta ruta usa el túnel como siguiente salto para llegar a las subredes remotas.

Por defecto, los extremos no saben si el otro lado ha caído. No tienen manera de trazarlo. Esto hace que las rutas instaladas permanezcan en la tabla de rutas, lo que puede traernos problemas. 

En túneles GRE se puede configurar un mecanismo para monitorizar los extremos. Usamos paquetes de tipo "keepalive" para ello:

[edit] user@host# show protocols { oam { gre-tunnel { interface gr-1/1/10.1 { keepalive-time 10; hold-time 30;           }       }    } }

Cuando configuramos "keepalive" debemos asegurarnos que en la interface del túnel añadimos la family inet al interface túnel.

set interfaces gr-0/0/0.0 family inet

También podemos usar el protocolo BFD (Bidirectional Forwarding detection) para monitorizar los túneles. Lo veremos en el capítulo de High-Availability

La MTU (Maximum Tasnmission Unit) depende del tipo de interface. El procolo IP amolda los diferentes valores de las MTU para fragmentar los paquetes si es necesario. El equipo que recibe estos paquetes fragmentados es el encargado de ensamblarlos. La fragmentación divide los paquetes en trozitos más pequeños. 

Cuando dos equipos se comunican usando TCP, determinan el tamaño máximo del segmento (MSS) permitido, que normalmente es de 1500, que es el máximo que permiten los enlaces Ethernet. Sin embargo, cuando usamos GRE el tamaño máximo del paquete se reduce de 1500 a 1476 por los 24 bytes que añade GRE (4 bytes de cabecera GRE + 20 bytes de la cabecera IP)

Si el equipo que transmite no fragmenta el paquete (DF bit), el router descarta el paquete y manda un paquete ICMP para notificar al emisor de que use un tamaño más pequeño.

Para solucionar este problems, configuramos la MTU a un tamaño superior. Si es para un túnel, Juniper recomienda 1524 o más. En algunos equipos Junos, podemos configurar la opcion "clear-dont-fragment", que en realidad hace que pueda fragmentar los paquetes. 

Debemos evitar el enrutamiento recursivo, es decir, que el túnel crea que para llegar al otro extremo se llega por el propio túnel (ya que es la mejor ruta para llegar). Como ya hemos dicho, los extremos tienen que tener una ruta activa para llegar al otro extremo, pero nunca a través del propio túnel. Si esto ocurre, el túnel dejaría de estar activo. Juniper recomienda que se configuren rutas estáticas para cumplir con este requerimiento.