Vous utilisez Supermicro IPMI derrière un proxy?

Il s'agit d'un serveur SuperMicro avec une carte mère X8DT3 qui contient un BMC IPMI intégré. Dans ce cas, le BMC est un Winbond WPCM450 ). Je pense que de nombreux serveurs Dell utilisent ce modèle BMC similaire.

Une pratique courante avec IPMI consiste à l'isoler sur un réseau privé non routable. Dans notre cas, toutes les cartes IPMI sont connectées à un LAN de gestion privé au 192.168.1.0/24 qui n'a pas de route vers le monde extérieur. Si je branche mon ordinateur portable au réseau 192.168.1.0/24, je peux vérifier que toutes les fonctionnalités IPMI fonctionnent comme prévu, y compris la console distante.

J'ai besoin d'accéder à toutes les fonctionnalités IPMI à partir d'un réseau différent, via une sorte de connexion cryptée.

J'ai essayé la redirection de port SSH. Cela fonctionne bien pour quelques serveurs, cependant, nous avons près de 100 de ces serveurs et maintenir une configuration client SSH pour transférer 6 ports sur 100 serveurs n'est pas pratique.

J'ai donc pensé essayer un proxy SOCKS . Cela fonctionne, mais il semble que l'application Remote Console n'obéit pas à mes paramètres de proxy à l'échelle du système.

1. J'ai configuré un proxy SOCKS. La journalisation détaillée me permet de voir l'activité du réseau et si les ports sont transférés.

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

2. Je configure mon système pour utiliser le proxy SOCKS. Je confirme que Java utilise les paramètres du proxy SOCKS.

3. Le proxy SOCKS fonctionne. Je me connecte au BMC à http://192.168.1.100/ à l' aide de mon navigateur Web. Je peux me connecter, afficher l'état du serveur, allumer ou éteindre la machine, etc. Étant donné que la journalisation détaillée SSH est activée, je peux voir la progression.

Voici où cela devient délicat:

3. Je clique sur le bouton "Launch Console" qui télécharge un fichier appelé jviewer.jnlp. Les fichiers JNLP sont ouverts avec Java Web Start.

4. Une fenêtre Java s'ouvre. La barre de titre indique "Visionneuse de redirection" dans la barre de titre. Il existe des menus pour "Vidéo" "Clavier" "Souris", etc. Cela confirme que Java est capable de télécharger l'application via le proxy et de démarrer l'application.

5. 60 secondes plus tard, l'application expire et dit simplement "Erreur d'ouverture de la prise vidéo". Voici une capture d'écran . Si cela fonctionnait, je verrais une fenêtre de style VNC. Mes journaux SSH ne montrent aucune tentative de connexion aux ports 5900/5901. Cela suggère que l'application Java a démarré l'application VNC, mais que l'application VNC ignore les paramètres du proxy à l'échelle du système et n'est donc pas en mesure de se connecter à l'hôte distant.

Java semble obéir à mes paramètres de proxy à l'échelle du système, mais cette application VNC semble l'ignorer.

Existe-t-il un moyen pour moi de forcer cette application VNC à utiliser mes paramètres de proxy à l'échelle du système?

Il semble qu'un VPN soit en fait votre meilleur choix. Ayez une ACL sur le routeur pour que le seul trafic non local doive traverser le VPN et vous avez terminé. Très simple et sécurisé ainsi que facile à gérer.

J'ai compris qu'il était préférable de ne pas utiliser de proxy de chaussettes pour cela, mais de transférer tous les ports nécessaires sur une adresse IP locale. Pour éluder tous les services existants, j'utilise une IP différente de 127.0.0.1. En supposant que vous avez choisi 127.0.0.2 et que votre serveur derrière le proxy soit 192.168.1.1, voici la commande ssh à utiliser:

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

Ensuite, vous pouvez parcourir https://127.0.0.2 et utiliser le KVM comme d'habitude.

Les ports TCP transférés sont 5900 et 5901 pour le contrôle et la vidéo, 5120 pour le CD virtuel et 5123 pour la disquette virtuelle (je n'ai pas testé les deux derniers). -C ajouté pour la compression, mais je ne sais pas si quelque chose envoyé convient à la compression.

Une autre méthode , légèrement plus confortable (et, en théorie, plus performante) sous Linux, consiste à utiliser sshuttle , qui transfère de manière transparente toutes les connexions TCP via ssh à l'aide d'iptables et d'un interpréteur python sur le serveur proxy.

sshuttle -r user @ proxy-server 192.168.1.1

Astuce: sshuttle est empaqueté dans Debian.

Ce que je ne pouvais pas encore transmettre, c'est le port UDP 623, qui peut être utilisé pour ipmitool, une connexion CLI pour IPMI. Il existe plusieurs didacticiels à ce sujet, mais aucun n'a fonctionné pour moi. Quoi qu'il en soit, Java KVM est assez bien.

Essayez tsocks , il devrait vous permettre d'exécuter n'importe quel processus via un proxy SOCKS en définissant LD_PRELOAD qui devrait fonctionner dans tous les sous-processus, voir ceci pour un exemple d'utilisation. Bien sûr, si vous utilisez ssh pour créer un proxy SOCKS, vous aurez toujours le problème UDP, mais cela devrait contourner le problème du sous-processus.