マシン(=クライアント)から別のマシン(=サーバー、実際にはLAN内にありますが、関係ありません)に(ssh -Y ...
を介して)接続します。次に、サーバーで新しいネットワーク名前空間(略してNNS)を開始し、クライアントに完全に表示されるxterm(デフォルトの名前空間から)を開始し、最後に、xterm内からデフォルト以外のNNSに参加します、
ip netns exec NNSName bash
新しいNNSにいることを確認できます。
ip netns identify $$
新しいNNS内からOpenVPNなどの複雑なプログラムを実行できます。
こすりはここにあります:新しいNNS内からグラフィカルアプリケーション(今のところxeyes
だけでも)を開始したいのですが、できません。常に次のように言われます:Unable to open DISPLAY=...
確かに、私は明白なことだけを試しました:
DISPLAY=:0.0
DISPLAY=:10.0
DISPLAY=localhost:10.0
DISPLAY=localhost:20.0
DISPLAY=ClientName:10.0
DISPLAY=ClientIPAddress:10.0
純粋なデバッグの目的で、クライアントでは常にxhost +
を使用します。
私は問題ありません:
ssh -Y ....
を介してクライアントからサーバーに接続し、サーバーでxeyes
を実行して、クライアントに表示します。
サーバーで新しいNNSを開始し、サーバーに表示されるNNS内のグラフィカルアプリケーションを開始します(つまり、この場合はクライアントを忘れます)。
サーバーの新しいNNSで実行されているクライアントアプリケーションに表示できないのは、これら2つのもの(sshと名前空間)を組み合わせたときです。
標準のTCPポート6010はデフォルトのNNSのsshセッションに属しているようですが、新しいNNSは独自のものを取得する必要があります。新しいNNSでsshサーバーを起動して、直接接続できます。クライアントからサーバーの新しいNNSに移動しますが、疑問に思っていました。これを行う簡単な方法はありますか?ieサーバーの新しいNNSで実行されているグラフィカルアプリケーションをクライアントのX11サーバーに表示しますか?
私も同様の状況にありました。これが私がそれを回避する方法です。
いくつかの背景:異なるIPアドレスでそれらをバインドするために、名前空間内のいくつかのSeleniumFirefoxインスタンスにまたがる必要がありました。しかし、ご存知のように、私はエラーを抱えていました:
Error: Can't open display: localhost:10.0
Mariusが提案したように、UNIXソケットを使用する代わりに、ローカルホストではなくSSHD X11Forwardingを*にバインドし(構成に「X11UseLocalhostno」を追加)、socatを使用して単純なTCP接続をリダイレクトしました。
これを行うことによるセキュリティへの影響に注意してください!!!!
Sshdでのこの変更後、これからログインすると、DISPLAYが自動的に変更されます。
DISPLAY=localhost:10.0
次のようなものに:
DISPLAY=10.0.0.1:10.0
その後、リダイレクトする必要があります:
ip netns exec my-NNS socat tcp-listen:6010,reuseaddr,fork tcp:192.168.5.130:6010 &
そうすれば、xeyes、firefox、x-whatever-you-wantで作業できるはずです...:
ip netns exec my-NNS xeyes &
そして、ボイラ!
実際、標準的な方法はないようです。
最も明白な解決策があります。ネットワーク名前空間内から、ssh
サーバーを起動し、通常のオプションを使用して任意のリモートマシンからサーバーに接続します。
ssh -Y [email protected]
その後、任意のグラフィカルプログラムをリモートマシンのX11サーバーで起動できます。 vnc
など、同じテーマのあらゆる種類のバリエーションも機能します。
または、通常の楽器を使用できます:iptables
、netcat
、socat
。これがsocat
でそれを行うoneの方法です:トリックは、サーバー上のlocalhost
スペースがまた、新しいネットワーク名前空間は分離されていますが、X11UNIXソケットは分離されていません。実際、ネットワーク名前空間から、親マシンのXサーバーに表示されるグラフィカルアプリケーションをすぐに開くことができます。したがって、ネットワークネームスペースに親マシンの新しいunixソケットへの書き込みを強制することで、通常のssh X11を使用して、新しいソケットに送信されたデータをclient Xサーバーにリダイレクトできます。サーバーマシンは、新しいネットワークネームスペースに接続することなく、よりシンプルなソリューションを提供します。
これは次のように行われます。新しいネットワーク名前空間では、
export DISPLAY=:1
これにより、まだ何にも接続されていない新しいUnixソケット/tmp/.X11-unix/X1
に書き込まれます。リモートクライアントで、コマンドを使用します
socat exec:'ssh me@remoteserver socat unix-l\:/tmp/.X11-unix/X1 -' unix:/tmp/.X11-unix/X0
(のエスケープに注意してください :)。上記のコマンドは、サーバーのunix/:1
ソケットの入力をクライアントのunix/:0
ソケットに送信します。ローカル(=クライアント上)xhost
コントロールを緩和し、unix/:1
(= :1
= /tmp/.X11-unix/X1
)ソケットの所有権を確認する必要がある場合があります。これは、以前の方法よりもかなり簡単です。新しいネットワーク名前空間にsshサーバーを設定する必要も、IPアドレスを取得する必要もありません。また、xhost
を使用して一部のリモートユーザーを許可したり、MITマジッククッキーとsocat
を使用したりするなど、X11認証のすべての問題をバイパスします(私もそうではありません)これができることを確認してください)。
これを行う方法は他にもあります(たとえば、クライアントXサーバーで-nolisten tcp
オプションを抑制し、socatを使用して:1
unixソケットをクライアントのポートTCP6000に転送するなど)が、それらが深刻なセキュリティ問題を引き起こすことを無視すると、それらは想像力の範囲によって標準ではありません。