Redirección ICMP
Hace unos días trabajé en un caso de los que llamo “muy interesantes” y que no tienen que ver con problemas de virus, corrupción de datos o malas configuraciones, sino estrictamente con protocolos y RFCs.
El escenario en cuestión constaba de un servidor en una DMZ, que necesitaba consumir algunos servicios de otros servidores ubicados en un sitio remoto. Para conectar la DMZ con el sitio remoto, se utiliza un Router con un enlace dedicado. La dirección IP interna del Router está configurada como default Gateway en el servidor.
Por razones de contingencia, se utiliza un Firewall PIX, conectado a la Internet, y capaz de establecer una conexión VPN con el sitio remoto. Cuando el enlace dedicado, y por lo tanto la conexión entre la DMZ y el sitio remoto se interrumpe, el PIX inicia la conexión VPN y restablece la conexión. En el Router se han configurado algunas políticas que redireccionan el tráfico hacia el PIX cuando el enlace principal no está disponible.
El escenario funciona perfectamente cuando perdemos el enlace principal; todo el tráfico del servidor destinado al sitio remoto es recibido por el Router y redirigido al PIX para su entrega vía la VPN.
El problema se presenta cuando se reestablece el enlace principal. En ese momento, el PIX termina la conexión VPN, y las políticas del Router dejan de aplicarse. Todo está listo para enrutar el trafico del servidor hacia el sitio remoto por el enlace principal… pero no hay trafico!
Al analizar el flujo del tráfico en el escenario descrito, al ocurrir una falla en el enlace principal observamos que el tráfico saliente del servidor es enviado al default Gateway, quien lo retransmite al PIX, tal y como las políticas lo indican. El tráfico entrante, dirigido al servidor, es entregado directamente por el PIX al servidor. Este comportamiento se mantiene durante algunos minutos, y luego, vemos que el tráfico saliente comienza a ser entregado directamente al PIX, en lugar de pasar por el Router (Default Gateway).
Al ejecutar el comando ROUTE PRINT en el server, observamos rutas estáticas directas a los servidores destino en el sitio remoto.
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 21 5d 4b 23 14 ...... HP NC373i Multifunction Gigabit Adapter
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.100 1
10.0.0.0 255.255.255.0 10.0.0.100 10.0.0.100 20
10.0.0.100 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.0.0.100 10.0.0.100 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.8.10 255.255.255.255 10.0.0.5 10.0.0.100 1
192.168.8.11 255.255.255.255 10.0.0.5 10.0.0.100 1
255.255.255.255 255.255.255.255 50.1.1.22 10.0.0.100 1
Default Gateway: 10.0.0.1
===========================================================================
Persistent Routes:
None
Básicamente, la ruta le dice al servidor que todo el tráfico dirigido a las direcciones IP 192.168.8.10 y 192.168.8.11 debe ser entregado al PIX, en lugar de al default Gateway.
Este comportamiento es causado por el mecanismo de redirección de ICMP, definida en los RFCs 972, 816 y 1349, implementado por Router, y soportado por los servidores Windows. Básicamente, el Router detecta que el servidor dispone de una mejor ruta para enviar la data e informa al servidor sobre esta ruta alternativa. Cuando el servidor recibe el mensaje implementa la nueva ruta creando entradas temporales en la tabla de enrutamiento. Las rutas creadas como consecuencia de mensajes de redirección de ICMP serán mantenidas por 10 minutos en la tabla de enrutamiento del servidor.
Si en el router utilizamos el comando
debug ip icmp
veremos en consola mensajes como:
ICMP:redirect sent to 10.0.0.100 for dest 192.168.8.10, use gw 10.0.0.5
El mecanismo de redirección de ICMP está habilitado en los servidores Windows de manera predeterminada, para deshabilitarlo es necesario editar el registro y modificar el valor de la llave “EnableICMPRedirect” de su valor original de “1” al valor “0”. De esta forma, el servidor ignorará cualquier mensaje de redirección que reciba.
La ruta completa es:
HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services\Tcpip\Parameters
Referencias
RFC 792, page 13:
"The gateway sends a redirect message to a host in the following situation. A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. The gateway forwards the original datagram's data to its internet destination."
RFC 816, page 3:
"The ICMP "redirect" message indicates that the gateway to which the host sent the datagram is no longer the best gateway to reach the net in question. The gateway will have forwarded the datagram, but the host should revise its routing table to have a different immediate address for this net."
RFC 1349, page 9:
"The ICMP Redirect message also includes a code, which specifies the class of datagrams to which the Redirect applies. There are currently four codes defined: 0 -- redirect datagrams for the network. 1 -- redirect datagrams for the host. 2 -- redirect datagrams for the type of service and network. 3 -- redirect datagrams for the type of service and host."