NetworkManager-ssh は接続済みと表示するが何もルーティングされない

メニューは SSH 接続を有効として表示し、ホスト鍵は受け入れられ、それでもブラウザは本来到達すべきどこにも到達していない。これは矛盾ではない。NetworkManager-ssh のプロファイルは、同じホストと同じ鍵からまったく異なる二つの結果を生みうる。パケットを運ぶトンネルデバイスか、特定のアプリだけが使える転送の集合かである。表示が報告するのは、管理された SSH 関係が存在するという事実だけである。二つのうちどちらを得たのかは決して報告しない。

一つのメニュー項目の背後にある二つの結果

どちらのモードも同じように認証する。だからこそ混同される。同じ資格情報でプロファイルをまったく同じように選んでも、ルーティングできるインターフェースが残ることもあれば、一つのアプリに知らせる必要のある待ち受けソケットが残ることもある。

まず、その作業が実際にどちらの結果を必要とするかを決める。サブネット全体への到達性が必要ならデバイスが要る。リモートホスト上の単一サービスなら転送が要り、そのためにトンネルを築くと、問題に見合っていた以上のルーティング作業が生じるのが普通だ。

動作させる前に各モードに必要なもの

プロジェクトは両方のモードを文書化しており、前提条件の差が大きいため、欠けている一つは設計上の選択ではなくプロトコルの失敗のように見える。

右の列をよく読んでほしい。こうしたチケットの多くはそこで終わる。完璧に築いたトンネルデバイスでも、ルーティングが中へ送るものしか覆わない。完璧な転送でも、使うよう言われたアプリしか助けない。

ダミーインターフェースはトンネルではない

転送モードでは、プラグインは接続モデルを満たすために作られるダミーインターフェースを文書化している。マネージャが状態を結び付ける先を持てるように存在する。任意のアプリのパケットを遠隔ネットワークへ運ぶものではなく、その存在は IP ルーティングが変わったことを何も意味しない。

プロジェクトの全トンネルの例は OpenSSH のトンネルデバイス対応に関するものだ。だからラベルの中のトンネルという語は能力を表しており、実際のポリシーではない。プロファイルの名前ではなく、カーネルが何をするかを確認しよう。

nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"

次に結果をアプリと突き合わせる。SOCKS を理解するプログラムはプロキシを使うよう設定する必要がある。ローカル転送の利用側はその待ち受け先を指定される必要がある。どちらも転送を自分で見つけることはなく、緑になった接続表示がどちらかの助けになることもない。

遠隔側を押しつけるのではなく整える

通常の SSH アカウントは、遠隔のトンネルデバイスを立ち上げる許可なしに認証できる。プロジェクトは root 権限なしの道筋を文書化しており、管理者がその利用者のためにデバイスを事前に作り、クライアントが対応する番号を選ぶ。

その取り決めには、サーバのトンネルポリシーと、遠隔ネットワークのアドレス管理を担う相手との調整が要る。デバイスを作ること自体は、リソースへの経路も転送の許可も戻り経路も与えない。サンプル設定が説得力に見えたからといって、それらが得られるわけではない。

やってはいけないのは、サンプルを動かすために無制限の転送や遠隔の root ログインを有効にすることだ。運用者が遠隔ネットワークの設定を担っている場合は、そのコマンドを所有者に委ねるサポートされた取り決めを使い、切断時に矛盾するアドレスを復元する二つ目の補助を避ける。

認証の文脈と、チケットに書くべきこと

認証には独自の文脈がある。プラグインは利用者セッションに関連付けられた SSH エージェントを探し、宛先ホストが既知であることを求める。だから一つの端末で動く鍵が、マネージャの認証経路に自動的に見えるわけではない。検査を切るのではなく、承認された手順でホスト鍵を登録し確認してもらう。

サポートのために四つを記録する。プラグインとその版、選んだモード、意図した遠隔の識別情報、そして現れるはずだったインターフェースまたは待ち受け先だ。そのうえでアプリの入口を直接試す。接続表示と動く試験がそろって証拠になる。接続表示だけでは SSH についての言明であり、得ようとしていたルーティングやリソース許可についてではない。