Colaboraciones: Consola remota a través de un NAT

Nestro amico Juan C. nos envía un tip sobre como acceder a una consola ESX tras un firewall.

"Buenas...
Hace tiempo te envíe una pregunta sobre la forma en que organiza la versión ESX 3 los discos, que había cambiado con respecto a la versión 2. Abriste un hilo para hablar un poco de ello y hace poco (un mes o así) te envíe de nuevo algo sobre el tema, pero al final, no sé si no te ha llegado o bien no lo envie. Je.
Bueno, ahora te envío otro problema que he tenido con el VI, lo bueno es que te envío el problema y la solución. No sé si te sonara el problema y quizás ya lo tengas por tu blog, pero bueno, yo te lo envío y si no lo tienes pues lo publicas o lo añades donde quieras, si quieres, je.
Verás, donde trabajo tenemos varios servidores ESX, generalmente todos en el mismo sitio y en la misma subred (interna). Por cuestiones varias, tuvimos que poner un ESX en la DMZ y por tanto, sacarlo de nuestra subred interna y ponerlo en otro rango de red. Pues bien, al hacer eso (de esto me di cuenta mas tarde) cuando accediamos a través del VI (VMware Virtual Infrastructure Client 2.0) para administrar las máquinas tuvimos un problema, concretamente cuando seleccionabamos una máquina ya creada y pulsabamos sobre la pestalla "console" nos aparecia un cuadro de dialogo con el siguiente mensaje:
"Error connecting. Cannot connect to host x.x.x.x: A connection attempt failed because the connected party did not respond after a period of time, or established connection failed because connection host has failed to respond"
Como puedes imaginar, me quede de piedra, ya ves, no podía acceder a la consola de la máquina. La cosa es que no había ningún problema a la hora de poder arrancarla o pararla, el "único" problema era que no había manera de ver la consola.
Después de mucho buscar y buzear encontré la solución, por lo menos en mi caso. Parece ser que ni la misma gente de VMware eran muy conscientes de que eso podía ocurrir. El problema viene como he dicho anteriormente, al conectar con el VI desde otra subred en la que está el ESX y la solución es añadir la siguiente linea dentro de "/etc/vmware/config":
vmauthd.server.alwaysProxy=TRUE
Haced un copy&paste para que no haya problemas con las mayúsculas y minúsculas.
Espero que a alguien le sirva.
Saludos."

He de reconocer que un servidor, desde chiquitito, siempre ha tenido la manía de mantener las redes de gestión (y la de service console de ESX lo es) dentro de la misma VLAN, así que no me he visto obligado a hacer NAT de este tipo de conexiones. Pero entiendo que hay otros entornos donde esto es inevitable.

Bien, efectivamente el problema existe, como podéis leer, además de en este post, en algunos threads de VMware. Mientras las conexiones de gestión se hacen a través del VC, la consola remota se hace contra el servidor ESX directamente. También el puerto IP cambia: Mientras el puerto de gestión es el 902, el de consola es el 903. El error de la conexión via NAT es un bug, donde el único workaround existente es el que comenta Juan C. Gracias por tu colaboración. Sé que te debo el post sobre el disco, no lo olvido.

Un abrazo.

VI3 y la red.

Otro de los aspectos fundamentales de la virtualización es la red. De nada nos vale virtualizar cualquier servidor si este no puede comunicarse eficientemente con el resto de servidores o con los clientes.

Uno de los grandes avances de VI3 respecto a las versiones anteriores de ESX es una gestión de la conectividad de las máquinas virtuales francamente avanzada. Antes de proseguir, aclaremos un poco el concepto de "Virtual Networking".

Virtual Switches.

VMware VI3 crea una capa de abstracción entre las máquinas virtuales y las interfaces de red físicas de la máquina host mediante los "Virtual Switches". Un "virtual switch", tal y como su nombre indica, es un dispositivo de red virtual a cuyos "puertos" conectamos las máquinas virtuales y que puede (o no) disponer de un "uplink" o enlace externo hacia una (o varias) tarjeta(s) de red del servidor ESX (o una VLAN de la misma). Estos switches se comportan exactamente igual que ese Catalyst, 3com o nortel que tenéis en el CPD, con unas cuantas diferencias:

- No hay Spanning Tree que valga.
- No son configurables (en el sentido de que no se aplican configuraciones específicas por línea de comando)
- Soportan de 8 a 1016 puertos, y son configurables (y reconfigurables) en ese aspecto.
- Todos sus puertos son a gigabit.
- No son aplilables/estacables dentro del mismo host.
- El ancho de banda del backplane (o switching fabric) es configurable.
- No hablan 802.1q (VLANs, para los menos puestos).

Cuando un virtual switch no tiene asignada una tarjeta del servidor ESX, el tráfico se encamina localmente dentro del ESX. Esto es de especial utilidad para Heartbeats, redes cerradas donde una de las máquinas virtuales enruta paquetes entre un Virtual Switch interno y otro externo o, para los fanáticos de la seguridad, para crear entornos de test de penetración seguros.

Gestión de ancho de banda de los Virtual Switches.

¿Tantos switches gigabit como quiera? ¿Y cómo evito que un par de servidores se coman el ancho de banda disponible?... tranquilos. VMware, tal como enumeré antes, permite definir el ancho de banda del backplane del switch virtual (para que nos entendamos, cuánto le dejamos mover a TODOS los servidores conectados a ese switch). ESX permite la definición de tres valores para controlar el ancho de banda de esos switches: El ancho de banda medio garantizado (Average Bandwidth), el ancho de banda Pico (Peak Bandwith) y la cantidad de tráfico máximo que ESX te permitirá enviar por encima del Average Bandwidth (y por debajo del Peak) antes de que venga el tio paco con las rebajas, es decir, antes de empezar a descartar el diferencial entre el exceso y el ancho de banda medio)... vamos, que para los que conozcáis Frame Relay, algo así como CIR y EIR.

Port Groups.

Un Port Group (Grupo de Puertos) es un conjunto de puertos virtuales dedicados a una determinada función. Cada port group es independiente del resto de port groups definidos en un swith virtual... algo así como la segmentación en los hubs (¿recordáis?)... para los más modernos, son VLANs (dominios de colisión separados) sin posibilidad de 802.1q.

Tipos de redes.

VMware asigna tres roles específicos a sus conexiones de red, y estos son los siguientes:

Consola de Servicio (Service Console): Es una IP para la gestión y acceso a los servidores ESX. Es, por decirlo así, la tarjeta de red de la consola. Sólo es usada para el acceso a la consola de VMware, y no puede ser usada por las máquinas virtuales o el kernel de VMware. Cada una de estas conexiones usa un puerto del switch virtual. Pueden existir tantos como puertos haya disponibles.

Puerto del Kernel de VMware (VMkernel Port): Son puertos de acceso del kernel de VMware al exterior. Se usan para el acceso iSCSI, NFS o vMotion. No pueden ser usados para las máquinas virtuales. Ocupan un puerto del switch virtual. Pueden existir tantos como puertos haya disponibles.

Grupo de puertos de máquinas virtuales (Virtual Machine Port Groups): Son el conjunto de puertos asignados a máquinas virtuales. Ocupan todos los puertos libres de un switch virtual.

la siguiente figura muestra un ejemplo de un Virtual Switch configurado con los tres tipos de redes:

La asignación de puertos es dinámica. Si disponemos de un virtual switch de 24 puertos y configuramos dos VMkernel Ports y tres service console, al crear un Virtual Machine Port Group, nos asignará automáticamente el resto de los puertos virtuales, es decir, tendremos conexiones para 19 máquinas virtuales.

Virtual Machine Port Groups.

Este bonito gráfico (que debemos agradecer a VMware) ilustra cómo funciona el networking en VMware. Como puede observarse, el Virtual switch asbtrae totalmente a las máquinas virtuales, que acceden al mundo "real" con sus propias MACs individuales, tal y como si estuviesen conectadas a un switch real. Nótese que el gráfico llama "outbound adapter" a la tarjeta de red que hace de "uplink" entre el switch virtual y la red real... pero esto también puede realizarse a través de una VLAN definida en el "outbound adapter" del host ESX. Este es, precisamente, uno de los aspectos que más versatilidad y potencia (y más esfuerzo de configuración) nos ofrece. El siguiente dibujo (lo siento, es mío, y no dibujo tan bien como la gente de VMware), ilustra este escenario.
Esto significa que, si como yo, sois unos adeptos a dividir redes, podemos extender el manto de la virtualización prácticamente a cualquier parte de vuestra red. Esto resulta de especial importancia cuando, por ejemplo, queremos virtualizar un portal web, lo que nos obliga a llevar los tentáculos de nuestro VMware a zonas dispersas o separadas de nuestro entorno de producción interno.

Seguiremos hablando del tema del networking, en escenarios más complejos.

Un Saludo.

J.