OpenVPNアプライアンスのルート：設定の所有者か起動スクリプトか

拠点ルートを追加し、それが機能しても、ファームウェア更新や Web UI からの保存で削除されます。その瞬間、ルートをアプライアンスのサポート対象の設定ソースに置くか、起動スクリプトから生成ファイルに追記するかという二つの修正が、同じくらい妥当に見えます。一週間は同じように動作し、二度目のアップグレードで分かれます。本記事は、それぞれが実際に何を所有するのかを比較します。

二つの候補は別のものを所有する

サポート対象の設定ソースとは、アプライアンスが入力として扱うすべてで、GUI のフィールド、インポートしたプロファイル、クライアントごとの文書化されたディレクトリ、管理パッケージが読む設定データベースなどが含まれます。生成された server.conf は出力です。出力の編集は、ジェネレーターが再び動くまで機能し、それは保存時、再起動時、アップグレード時に起こります。

スクリプトの手法は、ジェネレーターが終わった後にその出力へパッチを当てます。実験室では正当な手法ですが、拠点オフィスでは、ルートを文書化されたフィールドではなくテキスト照合に依存させるため、誤った既定値です。

アプライアンスが何をいつ再生成するか

管理パッケージは通常、設定をデータベースやテンプレート群に保持し、起動時にデーモンの設定を描画します。Web UI からの保存は、一行にパッチを当てるのではなくファイル全体を書き直すことがよくあります。変更がそのファイルにあったなら、今はもう消えており、アプライアンスから見れば何も失われていないので、警告も記録されません。

起動ラッパーには第二の故障モードがあります。特定の間隔を持つディレクティブへの grep は、テンプレート変更後に一致しなくなり、スクリプトは黙って何もしません。さらに悪いことに、ファームウェア更新がラッパーを新しい版に置き換え、パッチを一緒に持ち去ることがあります。その結果、一年間存在したルートが、誰もルーティングと結び付けなかった保守作業の間に消えます。

サポート対象の所有者が表現すべきこと

拠点のプレフィックスには三つの表明が必要で、一つではありません。クライアントはルートを学び、サーバーはどの認証済みクライアントがプレフィックスを所有するかを知り、拠点側は与えられたトンネルアドレスへ通信を戻さなければなりません。OpenVPN の用語では、プッシュされる route、クライアントに結び付いた対応する iroute、そして向こう側の戻り経路を意味します。

ここでアプライアンスの UI は誤解を招きます。「クライアントにサーバーの LAN へのアクセスを許可する」と表示されたチェックボックスは、サーバー自身のネットワークへの通信を表します。あなたの拠点は逆方向で、一つのクライアントの背後にあるネットワークがサーバー側から到達できます。同じ表示はそのサポートを意味せず、ファイル内の有効なディレクティブはパッケージがそれを保持するという約束ではありません。

サポートされた制御が存在しない場合

インストールされた版がピア固有のルートを本当に表現できないことがあります。その場合の正直な選択肢は、自分で制御する別のゲートウェイか、両端でサポートされたサイト間モードです。両端がそれを話す必要があります。サイト間と書かれた製品ページがあっても、任意の OpenVPN プロファイルが別プロトコルのトンネルと交換可能になるわけではなく、その組み合わせを強制すると、状態ページでは問題なく見える半接続のトンネルが生まれるのが普通です。

ネットワークを引き継ぐ人に一文で説明できる選択肢を選んでください。答えにスクリプトのパスとテキストパターンが必要なら、設計はすでに脆いのです。

意図を監査可能にする

契約をアプライアンスの外に、有効なクライアント識別、プレフィックス、戻りゲートウェイ、そしてそれぞれを供給するサポート対象のフィールドとして記録します。サポートされた仕組みで設定をエクスポートし、再構築の参照を残し、変更後だけでなく再接続、再起動、アップグレードの後にサービスを検証します。

何かが壊れたときは、説明のない行を戻して期待するのではなく、生成結果をその記録と比較します。OpenVPN 2.6 リファレンス は、UI と議論する前に route と iroute がどう相互作用するかを確認する場所です。

次の変更のためのチェックリスト：所有者を名指しし、三部構成の契約を述べ、意図をエクスポートし、自分の編集後ではなくアプライアンス自身のライフサイクルイベントの後に再テストします。