Netzwerk-Namespace, ssh, X11

Ich verbinde mich (über ssh -Y ...) von einem Computer (= Client) mit einem anderen Computer (= Server, tatsächlich in meinem LAN, aber das ist irrelevant). Dann starte ich einen neuen Netzwerk-Namespace (kurz NNS) auf dem Server, starte einen xterm (aus dem Standard-Namespace), der auf meinem Client perfekt angezeigt wird, und trete schließlich innerhalb des xterm dem nicht standardmäßigen NNS bei ,

ip netns exec NNSName bash

Ich kann überprüfen, ob ich im neuen NNS bin.

ip netns identify $$

und ich kann komplexe Programme wie zum Beispiel OpenVPN innerhalb des neuen NNS ausführen.

Das Problem ist hier: Ich möchte eine grafische Anwendung (auch nur xeyesfür den Moment) innerhalb des neuen NNS starten , aber ich kann nicht, mir wird immer gesagt:Unable to open DISPLAY=...

Zugegeben, ich habe nur das Offensichtliche versucht:

DISPLAY=:0.0
DISPLAY=:10.0
DISPLAY=localhost:10.0
DISPLAY=localhost:20.0
DISPLAY=ClientName:10.0
DISPLAY=ClientIPAddress:10.0

Immer mit xhost +auf dem Client, für reine Debugging-Zwecke.

Ich habe keine Probleme:

1. Herstellen einer Verbindung ssh -Y ....von Client zu Server, Ausführen xeyesauf dem Server und Anzeigen auf dem Client;

2. Starten eines neuen NNS auf dem Server und Starten von grafischen Anwendungen innerhalb des NNS, die auf dem Server angezeigt werden sollen ( dh in diesem Fall den Client vergessen).

Wenn ich diese beiden Dinge zusammenstelle (ssh und Namespace), kann ich sie nicht auf den Clientanwendungen anzeigen, die im neuen NNS des Servers ausgeführt werden.

Es scheint, dass der Standard-TCP-Port 6010 zur SSH-Sitzung mit dem Standard-NNS gehört, während der neue NNS seinen eigenen bekommen sollte. Ich kann sicherlich einen SSH-Server im neuen NNS starten und eine direkte Verbindung vom Client zum neuen NNS des Servers herstellen, aber ich habe mich gefragt: Gibt es eine einfachere Möglichkeit, dies zu tun, dh grafische Anwendungen anzuzeigen, die im neuen NNS des Servers auf dem Server ausgeführt werden X11-Server des Clients?

Ich war in einer ähnlichen Situation, hier ist, wie ich es umgehe.

Einige Hintergrundinformationen: Ich musste mehrere Selen-Firefox-Instanzen in Namespaces überspannen, um sie mit unterschiedlichen IP-Adressen zu binden. Aber wie Sie wissen, hatte ich den Fehler:

Error: Can't open display: localhost:10.0

Anstatt mit Unix-Sockets zu arbeiten, wie Marius vorgeschlagen hat, habe ich SSHD X11Forwarding nur an * anstelle von localhost gebunden (der Konfiguration "X11UseLocalhost no" hinzugefügt) und einfache TCP-Verbindungen mit socat umgeleitet.

Achtung der Sicherheitsfolgen dabei !!!!

Nach dieser Änderung auf sshd ändert sich das DISPLAY automatisch, wenn Sie sich von hier aus anmelden:

 DISPLAY=localhost:10.0

Zu so etwas wie:

 DISPLAY=10.0.0.1:10.0

Danach muss ich nur noch Folgendes umleiten:

ip netns exec my-NNS socat tcp-listen:6010,reuseaddr,fork tcp:192.168.5.130:6010 &

Dann sollten Sie in der Lage sein, mit xeyes, Firefox, x-was auch immer-Sie-wollen zu arbeiten ...:

ip netns exec my-NNS xeyes &

Und voilà!

Tatsächlich scheint es keine Standardmethode zu geben.

Es gibt eine naheliegende Lösung: Starten Sie im Netzwerk-Namespace einen sshServer und stellen Sie dann mit der üblichen Option von jedem Remotecomputer aus eine Verbindung her.

ssh -Y me@network.namespace.IP.address

Dann kann jedes grafische Programm auf dem X11-Server des Remote-Computers gestartet werden. Alle möglichen Variationen des gleichen Themas vncfunktionieren ebenfalls.

Alternativ kann man die üblichen Instrumente benutzen iptables, netcat, socat. Hier ist eine Möglichkeit, dies zu tun socat: Der Trick besteht darin, dass die localhostLeerzeichen auf dem Server und in seinem neuen Netzwerk-Namespace zwar getrennt wurden, die X11-Unix-Sockets jedoch nicht. Tatsächlich können Sie über den Netzwerk-Namespace sofort grafische Anwendungen öffnen, die auf dem X-Server des übergeordneten Computers angezeigt werden. Indem wir den Netzwerk-Namespace zwingen, auf einen neuen Unix-Socket auf dem übergeordneten Computer zu schreiben, können wir Daten, die an den neuen Socket gesendet werden, mithilfe der üblichen SSH X11-Weiterleitung auf dem Server-Computer an den Client X-Server umleiten , ohne eine Verbindung herzustellen Der neue Netzwerk-Namespace bietet eine einfachere Lösung.

Dies geschieht wie folgt: Im neuen Netzwerk-Namespace wird

export DISPLAY=:1

Dies schreibt in einen neuen Unix-Socket /tmp/.X11-unix/X1, der noch mit nichts verbunden ist. Verwenden Sie im Remote-Client den Befehl

socat exec:'ssh me@remoteserver socat unix-l\:/tmp/.X11-unix/X1 -' unix:/tmp/.X11-unix/X0

(Beachten Sie die Flucht der :). Der obige Befehl sendet die Eingabe des unix/:1Sockets auf dem Server an den unix/:0Socket auf dem Client. Möglicherweise müssen Sie die lokalen (= auf dem Client) xhostSteuerelemente lockern und den Besitz des unix/:1(= :1= /tmp/.X11-unix/X1) Sockets überprüfen . Dies ist erheblich einfacher als die vorherige Methode: Es muss weder ein SSH-Server im neuen Netzwerk-Namespace eingerichtet noch eine IP-Adresse abgerufen werden. Außerdem werden alle Probleme der X11-Autorisierung umgangen, z. B. die Verwendung xhost, um einige Remotebenutzer zuzulassen, oder die Verwendung von MIT-Magic-Cookies mit socat(ich bin mir nicht einmal sicher, ob dies möglich ist).

Es gibt andere Möglichkeiten, dies zu tun (z. B. indem Sie die -nolisten tcpOption auf dem Client X-Server unterdrücken und dann den :1Unix-Socket mit socat an den Client-Port TCP6000 weiterleiten), aber selbst wenn Sie vernachlässigen, dass sie schwerwiegende Sicherheitsprobleme verursachen, sind sie es kein Standard für jede Vorstellungskraft.