Redirección ICMP
Hace algún tiempo 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 de red y RFCs.
El escenario en cuestión consta de un servidor en una DMZ, que necesita consumir algunos servicios de otros servidores ubicados en un sitio remoto. Para conectar la DMZ con el sitio remoto, se utiliza un enrutador que nos conecta con un enlace dedicado. La dirección IP interna del enrutador 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 comunicación. En el enrutador 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 enrutador 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 enrutador dejan de aplicarse. ¡Todo está listo para enrutar el tráfico del servidor hacia el sitio remoto por el enlace principal… pero no hay trafico!
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 enrutador (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 Server 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 del default Gateway.
Este comportamiento es causado por el mecanismo de redirección de ICMP, definido en los RFCs 972, 816 y 1349, implementado por el enrutador y soportado por los servidores Windows. Básicamente, el enrutador detecta que el servidor dispone de una mejor ruta para enviar el tráfico 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 utilizamos el comando debug ip icmp
En el enrutador, 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 crear o 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, pagina 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, pagina 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, pagina 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.