¿Usando Supermicro IPMI detrás de un Proxy?

Este es un servidor SuperMicro con una placa base X8DT3 que contiene una BMC IPMI integrada. En este caso, el BMC es un Winbond WPCM450 ). Creo que muchos servidores Dell usan este un modelo BMC similar.

Una práctica común con IPMI es aislarlo en una red privada, no enrutable. En nuestro caso, todas las tarjetas IPMI están conectadas a una LAN de administración privada en 192.168.1.0/24 que no tiene ruta hacia el mundo exterior. Si conecto mi computadora portátil a la red 192.168.1.0/24, puedo verificar que todas las funciones de IPMI funcionen como se espera, incluida la consola remota.

Necesito acceder a todas las funciones de IPMI desde una red diferente, a través de algún tipo de conexión encriptada.

Intenté el reenvío de puertos SSH. Esto funciona bien para algunos servidores, sin embargo, tenemos cerca de 100 de estos servidores y no es práctico mantener una configuración de cliente SSH para reenviar 6 puertos en 100 servidores.

Así que pensé en probar un proxy SOCKS . Esto funciona, pero parece que la aplicación Consola remota no obedece a la configuración de proxy de mi sistema.

1. Configuré un proxy SOCKS. El registro detallado me permite ver la actividad de la red y si los puertos se reenvían.

   ssh -v -D 3333 stefanl@gateway.example.org
   

2. Configuro mi sistema para usar el proxy SOCKS. Confirmo que Java está utilizando la configuración del proxy SOCKS.

3. El proxy SOCKS está funcionando. Me conecto al BMC en http://192.168.1.100/ usando mi navegador web. Puedo iniciar sesión, ver el estado del servidor, encender o apagar la máquina, etc. Dado que el registro detallado de SSH está habilitado, puedo ver el progreso.

Aquí es donde se pone difícil:

3. Hago clic en el botón "Iniciar consola" que descarga un archivo llamado jviewer.jnlp. Los archivos JNLP se abren con Java Web Start.

4. Se abre una ventana de Java. La barra de título dice "Visor de redireccionamiento" en la barra de título. Hay menús para "Video", "Teclado", "Ratón", etc. Esto confirma que Java puede descargar la aplicación a través del proxy e iniciarla.

5. 60 segundos después, la aplicación agota el tiempo de espera y simplemente dice "Error al abrir el socket de video". Aquí hay una captura de pantalla . Si esto funcionara, vería una ventana de estilo VNC. Mis registros SSH no muestran intentos de conexión a los puertos 5900/5901. Esto sugiere que la aplicación Java inició la aplicación VNC, pero que la aplicación VNC ignora la configuración del proxy en todo el sistema y, por lo tanto, no puede conectarse al host remoto.

Java parece obedecer mi configuración de proxy de todo el sistema, pero esta aplicación VNC parece ignorarla.

¿Hay alguna forma de obligar a esta aplicación VNC a usar la configuración de proxy de todo el sistema?

Parece que una VPN podría ser tu mejor apuesta. Tenga una ACL en el enrutador para que el único tráfico no local tenga que atravesar la VPN y listo. Muy simple y seguro, así como fácil de administrar.

Descubrí que es mejor no usar un proxy de calcetines para esto, sino reenviar todos los puertos necesarios en una IP localhost. Para evadir cualquier servicio existente, utilizo una IP diferente a 127.0.0.1. Suponiendo que eligió 127.0.0.2, y su servidor detrás del proxy es 192.168.1.1, este es el comando ssh que debe usar:

ssh user @ proxy-server -L127.0.0.2: 443: 192.168.1.1: 443 -L127.0.0.2: 5900: 192.168.1.1: 5900 -L127.0.0.2: 5901: 192.168.1.1: 5901 -L127 .0.0.2: 5120: 192.168.1.1: 5120 -L127.0.0.2: 5123: 192.168.1.1: 5123 -C

Luego puede navegar por https://127.0.0.2 y usar el KVM como de costumbre.

Los puertos TCP reenviados son 5900 y 5901 para control y video, 5120 para CD virtual y 5123 para disquete virtual (no probé los dos últimos). Se agregó -C para la compresión, aunque no sé si algo enviado es adecuado para la compresión.

Otro método , un poco más cómodo (y, en teoría, con mejor rendimiento) en Linux, es usar sshuttle , que reenvía de forma transparente todas las conexiones TCP a través de ssh usando iptables y un intérprete de Python en el servidor proxy.

sshuttle -r usuario @ servidor proxy 192.168.1.1

Sugerencia: sshuttle se está empaquetando en Debian.

Lo que no pude reenviar aún es el puerto UDP 623, que se puede usar para ipmitool, una conexión CLI para IPMI. No son varios tutoriales sobre esto, pero ninguna funcionó para mí. De todos modos, Java KVM está bastante bien.

Pruebe tsocks , debería permitirle ejecutar cualquier proceso a través de un proxy SOCKS configurando LD_PRELOAD, que debería funcionar en todos los subprocesos, vea esto, por ejemplo, el uso. Por supuesto, si está utilizando ssh para crear un proxy SOCKS, todavía tendrá el problema UDP, pero esto debería solucionar el problema del subproceso.