あなたの .ovpn ファイルは通信を流すだけでなくコードを実行できる

ほとんどの人は .ovpn ファイルをルーターの設定画面を読むように読む。アドレス、ルート、暗号の一覧。コードを実行する部分は下端近く、配管作業のように見える指令の隣にあり、クライアントがすでに持っている権限で動く。そこが不注意な、あるいは悪意あるプロファイルが突く隙間であり、役に立つ DNS ヘルパーを三週間後にサポート問題へ変える隙間でもある。イベント指令、セキュリティ水準、ファイルの所有権が何が起こり得るかを決め、スクリプトの中身が実際に何が起こるかを決める。接続する前に四つとも読んでほしい。

ヘルパーを実行するプロファイルは設定ファイルではなくプログラムだ

route や dhcp-option といった指令は、クライアントが確立すべき状態を記述するもので、クライアントはそれをデータとして扱う。up スクリプトは違う。クライアントはそれをプロセスとして起動し、接続の詳細でいっぱいの環境を渡すので、作者が書いたものはあなたのアカウントの権限で動く。利用者が管理者であるノート PC では、添付ファイルとして、あるいはフォーラムのスレッドから貼り付けられたファイルにとって、それは広い扉になる。区別は様式の話ではなく、設定とコードの違いだ。

捨てるべき俗説は、プロファイルは通信を迂回させることしかできないというものだ。ip route add を実行するヘルパーも、遠隔ホストに対して curl を実行するものも同じ仕組みで、外から見たプロファイルは同一である。ファイルの見た目からはどちらか分からない。だからこそ確認はスクリプト本体まで届かねばならない。

実際に実行を決めるもの、そして有効化する行の姿

ヘルパーを左右するのは三つ。名前を与えるイベント指令、それを許す script-security の水準、そしてクライアント基盤自身の実装だ。プロファイルがフックを要求しても何も起きないことがある。モバイルのクライアントや削ったデスクトップ版がそのイベントを実装していないかもしれないからだ。同じように、機能に必要な以上の許可を求めるプロファイルは出自について何かを語っている。許可の水準は能力であり、承認ではない。有効化の行はこうなっていて、パスはあなたのものの代わりに置かれる。

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

水準 0 は外部プログラムを拒否し、既定の水準 1 はクライアント内蔵の実行ファイルだけを許すので、フックには 2 以上が要る。水準 3 は主に古いパスワード受け渡しのためにあり、避けるのがよい。フック付きで配布されたプロファイルは指令とその水準の両方を要する。だからファイル下端近くの一行は証明書ブロックと同じ吟味に値する。OpenVPN のマニュアルは許可の水準を列挙しており、その文言はプロファイルが実際に求めるものと並べて読む価値がある。

所有権、パス、そしてヘルパーに与えられるもの

信頼しているプロファイルが、別のアカウントが書き換えられるスクリプトを指しているなら、それは信頼できる取り決めではない。昨日の確認は今日動くものを記述していないからだ。ヘルパーの所有者とモードを確かめ、設定されたパスが、あなたが調べたファイルに解決すること、何かに影を落とされ得る名前に解決しないことを確かめる。引数と環境も同じ目で見るべきだ。クライアントは接続の詳細をフックに渡し、環境のすべてを記録するヘルパーはサポートチケットに資格情報を書き込んでいるかもしれない。無関係な記事からコピーした DNS スクリプトより、事業者や基盤が文書化した統合を選ぶこと。二つのリゾルバ管理者が同じファイルを奪い合えば、壊れた VPN に見える障害が生まれる。

失敗したフックを報告するときは、どこかに貼る前に環境を伏せること。デバッグに役立つダンプは、あなたを認証するトークンも運んでいることがある。

後片付けの失敗はトンネルが消えた後に現れる

up ヘルパーはルートとリゾルバ設定を加え、down ヘルパーがそれらを再び取り除くはずだ。down フックが無い、静かに失敗する、あるいはクライアントが強制終了されて決して走らないと、残り物はセッションより長生きする。すると通信は誰も計画しなかった経路を通り、名前は削除されているはずのリゾルバで解決され、トンネル自体は健全に見える。こうした症状は切断後に現れるので、プロファイルではなくネットワークのせいにされる。

解体を独立した手順として試すこと。トンネルを上げ、ルートとリゾルバを記録し、落としてから、両方が消えたことを確かめる。きれいに接続するプロファイルでも状態を残すことがあり、ヘルパーの終了コードがゼロでも、リゾルバが思う場所に落ち着いた証明にはならない。

ヘルパーを確認し、出口を確保する

スクリプトを最初から最後まで読み、三つを探す。権限を要するコマンド、あなたのシステムに無いかもしれない固定パス、そして行われるあらゆるネットワーク呼び出し。次に、それがどう失敗するかを見る。エラーを飲み込むヘルパーは設定の誤りを謎に変える。スクリプトが何をして誰が変えられるかを一文で言えないなら、有効化の準備はできていない。その一文が必要とする以上の権限を求めるプロファイルは、止まれという合図だ。

最後に動いたプロファイルとそれが参照したヘルパーを保護された保管場所に置き、両方の版を記すこと。そうすれば切り戻しは、最悪の瞬間の再構築ではなくコピーになる。ヘルパーが、もはや必要としないディストリビューションやクライアント版のためだけに存在するなら、エラーが止むまで権限を上げるのではなく、その設定を所有する構成の中で引退させる。それが出口だ。可動部品を減らすのであって、許可を増やすのではない。