Proxy ARP en VMware NSX: funcionamiento y consideraciones (Parte 1/2)

Proxy ARP es un mecanismo utilizado en redes y seguridad desde hace décadas. Consiste en configurar un dispositivo de capa 3 (típicamente un router) para que responda a las solicitudes de ARP (traducción de IP a MAC address) con su propia MAC Address, evitando que el dispositivo que hizo la solicitud tenga que salir de la red para hacer la consulta y convirtiéndose, a su vez, en el punto designado por el cual se redirijan (forwarding) las subsiguientes sesiones de comunicación hacia la recién aprendida IP/MAC.

Dicho de otro modo, si dispositivos conectados en subredes diferentes requieren conectarse entre sí van a necesitar un router que actúe ademas como el default gateway para cada subred, esto es Networking 101 o menos para muchos. Pero ¿que pasa si no hay tal dispositivo? ¿Podría insertar un dispositivo que facilite esa comunicación incluso SIN configurar un gateway  para ninguna de las sub-redes? Esto es precisamente para lo que hace casi 30 años se concibió ProxyARP documentado inicialmente en el RFC 1027 (lectura interesante)

Utilidad

  • Introducir ProxyARP en la red no implica cambios en las tablas de enrutamiento de otros dispositivos en la red. Realmente, éste puede ser un beneficio que se pase por alto pero si hablamos de un entorno virtualizado donde es tán fácil crear VMs con múltiples vNICs, y si dicho entorno aun cuenta con un esquema tradicional de VLANs, entonces esas tablas pueden estar llegando a su límite operacional; que es más cercano de lo que pensamos como lo confirma el RFC 5556 (TRILL).
  • Por otro lado, habilita la creación de un modelo de red plana (flat-network) sin intervenir los dispositivos finales que, gracias a ProxyARP, piensan estar directamente conectados con dispositivos en las demás sub-redes. Esto puede habilitar el diseño de una DMZ en la cual los equipos no cuenten con un gateway configurado.

Dificultades

ProxyARP no es nada popular en muchos círculos, algunas de las razones que se esgrimen para ello son:

  • Afecta la confidencialidad de la red más de lo que la beneficia: si un atacante logra hacerse pasar como la MAC address del ARP Proxy (MAC-spoofing) entonces tendrá visibilidad de todo el tráfico de sesiones establecidas así como de consultas ARP.
  • Debido a que los dispositivos (por ejemplo máquinas virtuales) no pueden pasar a otra sub-red sus solicitudes ARP, la presencia del proxy a largo plazo eleva el volúmen de tráfico ARP que tiene que ir y regresar a la subred.
  • Como si no fuese suficiente, debido a que siempre habría una respuesta a una solicitud ARP, el dispositivo que originó la consulta confía en que efectivamente encontró el destino y continuará el envío de paquetes hacia allí. Sin embargo, en ningún punto el proxy verificó que efectivamente pudiese llegar al destino real. Esto crea el llamado efecto hoyo negro, pues se establecerá una “comunicación” que realmente no está llegando a ningún destino y los dispositivos no lo notan.

De aquí en adelante, ¿para qué hablar más de Proxy ARP? ¿Es completamente fallido? ¿Alguien lo sigue utilizando?

Veamos.

Proxy ARP en VMware NSX

Si eres nuevo en NSX, recomiendo ampliamente el webinar de arquitectura desarrollado por ipSpace (el hombre, la leyenda Ivan Pepelnjak)

En NSX, el plano de control es distribuido y el rol le pertenece a un cluster de Controllers (virtual appliances) que aprenden y distribuyen la información de forwarding a todos los VTEPs participando en la red para VXLAN.

Una de las funciones que provee el controller cluster se conoce como “ARP Supression” en la que habilita a los VTEPs instalados en los hosts ESXi para actuar como ARP Proxy cuando una VM hace una solicitud de ARP broadcast para resolver la MAC address de otra VM. Quizá sea más claro con una imagen (tomada de la guía de diseño de NSX-v):

image

Trataré de ampliar lo descrito por la guía de diseño (de otro modo, Google Translator habría sido en vano):

1. La VM1 pregunta “¿Dónde esta la dirección física de ésta dirección IP?”. Eso, en suma, es una solicitud ARP (“dónde ubico la MAC address corrrespondiente con ésta IP address). Normalmente esa amplia pregunta (broadcast) se hace en todo el dominio L2 de la VM, es decir, en su red VXLAN 5001 y, debido a que ésa red atravies múltiples hosts, la consulta se haría sobre múltiples puertos físicos. Esto es lo que tratará de evitar el “ARP supression”.

2. Antes de obedecer ciegamente la solicitud de la VM1 y pasarla a hacer broadcast a lo largo de todos los hosts en el Transport Zone, ESXi-1 le pasa la solicitud al Controller Cluster: “¿Dónde esta la dirección física de ésta dirección IP?”

3. El controller cluster recibe la solicitud. Nota para candidatos a VCIX-NV: el agente que lleva a cábo ésta comunicación se llama netcpa y se comunica con el Controller Cluster a través de un canal SSL establecido en el momento en que se prepara el cluster para NSX.

4. El controller hace lo que cualquier dispositivo L2 haría: consultar su tabla ARP local a ver si tiene ese registro.

5. En caso de contar con la respuesta, se la envía de vuelta al host ESXi-1

6. El host ESXi-1 hace lo que todo dispositivo de L2 en ése caso: recibe el mensaje del plano de control y actualiza su tabla local pero fíjense: lo que guarda en su tabla es la IP y MAC address del VTEP del host ESXI-2 donde se encuentra la VM2, no la información sobre la VM2 específicamente.

7. Aquí viene el truco: ESXi-1 fabrica una respuesta ARP en la cual la MAC address origen no es realmente la MAC de la VM2, sino la del VTEP del ESXi-2 que, de aquí en adelante, actuará como el ARP proxy para ésta comunicación.

Claro está, si en el paso 4 el controller determinó que NO cuenta con ésa entrada, entonces ejecutará el L2 broadcast y cuando tenga una respuesta de la red, actualizará su tabla y le informará el cambio a los hosts ESXi.

¿Qué pasa si la VM es migrada a otro host? En condiciones normales, al ejecutar vMotion ESXi envía, como parte del proceso, un ARP reverso (RARP) para actualizar las entradas ARP, por lo que una nueva comunicación entre VM1 y VM2 (que ahora está en el host ESXi-3) no debe pasar por el proceso de ARP descrito. En todo caso, tener en cuenta lo descrito en este KB, pues podría evitar el funcionamiento del RARP.

En la siguiente entrada, hablaremos más de funcionalidades similares que NSX despliega para la comunicación optimizada entre VXLAN y redes tradicionales basadas en VLAN.

Bienvenidos los comentarios!

Advertisements