ifconfig-noexec は SSH セッションを救わない: 実際に何をするのか

とあるフォーラムのスレッドで、ifconfig-noexec は、トンネルが上がったときに SSH セッションを生かし続ける修正として勧められている。その理屈はもっともらしく聞こえるが、このオプションが何に触れるのかを確かめるまでは信用できない。これは OpenVPN がトンネルインターフェースのアドレスを設定するのを止め、その値を代わりにスクリプトへ渡すが、管理用接続への応答がどこへ行くかについては何も語っていない。逆に信じると、使えるアドレスのないトンネルと、それでも切れてしまう SSH セッションが残る。

このオプションが実際に委ねるもの

既定では、クライアントがトンネルデバイスを立ち上げ、サーバーから渡されたローカルアドレスとリモートアドレスを割り当てる。ifconfig-noexec を設定すると、その手順は飛ばされ、折衝済みの値はスクリプトの環境へエクスポートされ、別の何かが適用できるようになる。

所有権が移る。その代わりに何かが作られるわけではない。

つまりこのオプションが答える問いは「誰がインターフェースを設定するか」であり、答えない問いは「パケットがどうやって自分のところへ戻ってくるか」だ。この二つは分けて考えないと、アドレスのないインターフェースを埋め合わせるために一晩ルートを編集することになる。

似ているが役割の違う三つのオプション

名前が一語しか違わず、症状も重なるので、この一族は混同しやすい。どれかを選ぶ前に、それぞれが何を抑止するのかを読んでほしい。

これらは個別に理解すべき選択肢であり、まとめて貼り付けるセットではない。アドレス設定を抑止しても、ルート変更、ファイアウォール規則、DNS を運ぶプッシュ済みオプションは抑止されない。委ねたスクリプトもルートを自由に変えられるが、それは避けるのではなく、こちらが引き渡している判断だ。

ベンダーのクライアントがエンジンを包んでいるなら、プロファイルに低レベルの指示を放り込んでラッパーが従うことを期待するのではなく、そのクライアントが対応している統合を使う。ラッパーは接続のたびにプロファイルを再生成することが多く、手作業の編集はエラーも出さずに消える。ファイルに一晩費やす前に、クライアントが設定をどこに置くかを確認しよう。これは表のどの行にも当てはまり、自分が目当てにした行だけの話ではない。

守りたかった SSH セッション

SSH 接続には送信元アドレス、宛先アドレス、そして応答経路がある。フルトンネルの既定を入れたばかりのサーバーでは、公開アドレスへの応答がトンネルと一致してしまい、VPN ゲートウェイがそれを捨てる。

トンネルインターフェースのアドレス設定のどこを変えても、それは変わらない。

これを直すのは、トンネル前のゲートウェイ経由で管理アドレスに向かうより具体的なルートか、その通信を誘導するポリシールール、さらにホストが適用するフィルター設定だ。二つの問題は同時に現れることがあり、そのせいで一方がもう一方の治療法だと誤解される。オプションなしでトンネルを上げ、インターフェースのアドレスと応答経路を見て、どちらが本当に壊れているかを別々に確かめる。

委ねたスクリプトが引き受けるべきこと

本当に別の所有者にインターフェースを設定させたいなら、ローカルとリモートのアドレスを適用し、デバイスを立ち上げ、切断時にアドレス指定を復元または削除し、再接続後に同じことをもう一度行う、という作業を列挙しよう。成功したセッションの値をハードコードしてはいけないのは、次回サーバーが別の組を渡すかもしれないからだ。

クライアントがエクスポートする環境変数が、その作業で唯一サポートされる入力だ。

env | grep -E '^ifconfig_|^route_'

いずれかの route-up スクリプトの中ではそれらの変数が使えるが、cron ジョブや手動のシェルからは使えない。自分のバージョンがどのライフサイクルフックを使うのか、そのフックがインターフェースを変えるのに十分な権限で動くのかを確認する（クライアントはすでに非特権ユーザーへ降下しているかもしれない）。

一つのセッションではなく、ライフサイクル全体を試す

トンネルを上げ、デバイスのアドレスを確認し、再接続してもう一度確認する。一度は動いて二度目に失敗する設定は、たいてい委ねた手順が最初の接続でしか走らないことを意味する。

そのうえで、意図した管理経路を通る新しい SSH 接続が通り、許可されたアプリケーションがトンネルを正しく使うという二つの受け入れ基準を同時に試す。

トンネルにアドレスがないのに古い SSH セッションがたまたま生き残っているのは成功ではなく、誰も作業を引き受けなかったときにこのオプションが作るのはまさにその状態だ。まずインターフェースのアドレス、次に管理の応答経路、最後にアプリケーションを確認する。三つのうち二つが間違っているなら、このオプションは作業を移しただけで所有者を与えていない。