web-dev-qa-db-ja.com

リモートホスト名を介したポート転送は接続できず、IPを介して機能します

Mariadbサーバー（「DBサーバー」）にアクセスできるリモートサーバー（「ジャンプサーバー」）にssh経由でローカルポート転送を実行しようとしています。ジャンプサーバーのパブリックIPアドレスは1.2.3.4で、DBサーバーの内部IPアドレスは10.5.6.7です。次のコマンドは期待どおりに機能します。

ssh -v -N [email protected] -L 3306:10.5.6.7:3306

ただし、DBサーバーの内部IPアドレスは静的ではないため、内部ホスト名mariadb.localに依存したいと思います。ただし、以下は機能しますnot動作します：

ssh -v -N [email protected] -L 3306:mariadb.local:3306

ジャンプサーバー上のsshdから次の出力を生成します。

debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_global_request: rtype [email protected] want_reply 0
debug1: server_input_channel_open: ctype direct-tcpip rchan 2 win 2097152 max 32768
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 58953, target mariadb.local port 3306
connect_to mariadb.local: unknown Host (Try again)
debug1: server_input_channel_open: failure direct-tcpip

したがって、DNS解決の問題である必要があるように見えますが、ポート転送中にDNS解決がどのように機能するかわからないため、ここで私の知識が壊れます。明確にするために、これはジャンプサーバーからのpingの結果です。

/ # ping mariadb.local
PING mariadb.local (10.5.6.7): 56 data bytes

注：この環境全体は実際にはkubernetes内にあるため、ホスト名mariadb.localはサービスとして利用可能になり、k8scoreDNSを介して解決されます。ただし、それが何かに影響する理由がわからないため、問題をさらに複雑にすることを避け、「kubectlport-forwardを使用する」という提案を避けるために問題のメインの説明から省略しました。 kubectlにアクセスを許可したくないユーザーがこのサービスを利用できるようにしたいので、これはオプションではありません。

networkingsshssh-tunnelinternal-dns
2
Leon Aves

問題は、ユーザーがchrootされたことでした。これは、UsePrivilegeSeparationがオンの場合（openSSH 7.5では必須）、フォークされたプロセスもchrootされます。

明らかに、これが原因で、ホスト名を正しく解決するために必要な/etc/resolv.confをプロセスが読み取れなくなりました。これにはいくつかの 解決策 がありますが、基本的にこのような問題が発生している場合は、何らかの理由でresolv.confが読み取れない可能性があります（別の考えられる問題は、そのアクセス許可です）ファイル）。

3
Leon Aves