SSH SOCKS 転送は TUN デバイスのエラーとは別物
同じ SSH セッションが後で別の TUN デバイスの作成に失敗しても、確立済みの SOCKS リスナーを見分けましょう。
これらの 2 つの観測は、1 つの SSH ログに同時に現れることがあります:
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.1 つ目は動的な SOCKS リスナーに関するものです。2 つ目はトンネル用ネットワークデバイスに関するものです。両者は別々の転送要求です。
OpenSSH はアプリケーション層の動的転送に -D を、トンネルデバイスに -w を使います。Tunnel 設定でも構成ファイル経由で後者を要求できます。TUN デバイスの権限やサーバー側の許可が得られなかったことは、それ自体では、先の SOCKS リスナーが作られなかった証拠にはなりません。
エラーより前に何が成功したかを読み取ります。SSH 認証、リスナーの作成、そしてその後の宛先チャネル要求です。待ち受け中の SOCKS ポートには、なお互換クライアントと到達可能で許可された宛先が必要です。これは 1 つの段階についての証拠です。
目的が SOCKS 転送だけなら、そもそもなぜトンネルデバイスが要求されたのかを確認します。範囲を限定した構成で、その無関係な要求を無効にできます:
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]通常の SSH ホスト鍵とアカウントの確認は残します。SOCKS 経路に不要な機能のエラーを黙らせるためだけに、ネットワークデバイスの権限を与える理由はありません。