OpenVPNサーバーの設定を拠点にコピーしても失敗する理由
拠点クライアントには独自の識別情報、クライアント役割のプロファイル、そしてハブがそのピアに結び付ける経路が必要です。サーバーファイルをコピーすると誤った役割をコピーします。
動作しているサーバー設定をコピーし、いくつかのアドレスを入れ替えて、それを拠点プロファイルと呼ぶと、たいていは接続ができてしまいます。これは最悪の結果です。拠点は誤った役割のまま動き、ハブから出すべきでない素材を露出し、誰も作った覚えのない経路の関連付けを残すからです。その接続は三つの問題を同時に隠しており、誰かが確認する前にトンネルが上がってしまいます。
拠点を、独自の識別情報とネットワーク上の役割を持つピアとして扱うことが、プロファイルを正しくします。修正はより良いコピーではなく、このページの残りはクライアントが実際に何を持つべきかを扱います。
一つのファイルに見える二つの役割
TLSモードでは、二つの側の仕事は補完的です。一方は待ち受け、サーバー証明書と鍵を保持し、どのクライアントが接続できるかを決めます。もう一方は接続を開始し、待ち受け側を検証して、自分の識別情報を提示します。
サーバーファイルにはクライアントでは意味をなさない指示が含まれます。待ち受けるバインドアドレスとポート、配布するアドレスのプール、そして多くの場合クライアントが受け取るべき設定のプッシュリストです。それらを拠点にコピーすると、待ち受け側とクライアントを同時に務めようとする機器ができます。
最も重要なのは秘密鍵です。クライアントはサーバーの秘密鍵を決して持ってはならず、CAの署名鍵も必要ありません。CA証明書は公開の信頼素材であり、署名鍵は証明書を発行する場所に属します。
拠点プロファイルに必要なもの
拠点プロファイルには、遠隔のエンドポイントとトランスポート、信頼するサーバーの識別情報、拠点自身の証明書と鍵、そして拠点が実際に必要とする経路とDNS設定が必要です。それ以外は必須ではありません。
拠点の識別情報は拠点ごとに分けてください。二つの拠点が一つの証明書を共有すると、片方の失効がもう片方を止め、ハブのログでは区別できません。拠点ごとの識別情報が、監査の記録と失効の筋書きの両方を成り立たせます。
機器のワークフローには注意してください。pfSenseのClient Exportパッケージは適格なRemote Accessのコンテキスト向けにプロファイルを作り、そのサーバー一覧にはRemote Accessモードで設定されたサーバーしか含まれません。別のモードの拠点間サーバーは現れず、その不在は情報であって、サーバーの秘密をコピーする招待ではありません。
機器が必要なプロファイルを書き出さない場合は、文書化された拠点間クライアントのワークフローを使うか、インストール済みリリースのサポートされる例からプロファイルを組み立ててください。サーバーのバックアップを拠点に書き出すのは、計画がサーバーの復元である場合だけであり、ここではそうではありません。バックアップはハブの私有素材も運ぶため、拠点への移動は鍵の扱いに関する判断であり、ファイル転送ではありません。ハブに置いたままにし、クライアントの識別情報は証明書を発行する場所で作ってください。
ピアとネットワークの関連付けは別物
接続に成功した拠点クライアントでも、ハブがこのピアがそのプレフィックスを所有すると知るまでは、自分のLAN向けの通信を通せません。その関連付けはハブ上にあり、クライアントの識別情報に紐づいており、拠点自身の遠隔ネットワークへの経路とは別です。これがなければ、拠点のホストはトンネルの統計では到達可能に見え、実際には到達できません。関連付けが適用されたかを確認するのはハブのログです。
ハブのオペレーティングシステムに経路を追加することは、どのクライアントがプレフィックスを所有するかをOpenVPNに伝えることと同じではありません。クライアントごとの関連付けがなければ、パケットはトンネルのインターフェースに届き、どのピアも宛先を主張しないため破棄されます。
拠点側で対応する必要は、到達すべきネットワークへの経路と、通信を拠点に戻す方法を知っているLANルーターです。サーバー側の所有とクライアント側の宛先経路は別の対象であり、動作するトンネルは最初の一跳びしか証明しません。両方を拠点の引き継ぎメモに書いてください。次の技術者はそのうち片方しか見つけません。
拠点が思っているピアであることを証明する
通信を検証する前に識別情報を検証してください。ハブのログには拠点の証明書のコモンネームが表示されるはずで、クライアントが受け取ったアドレスは意図したプールまたは固定割り当てと一致するはずです。ログに別の名前が出ていれば、そのプロファイルは他人の識別情報を運んでいます。
次に、拠点のホストからハブ側の資源へ要求を一つ送り、期待した送信元アドレスで成功することを確認して関連付けを検証します。拠点が到達してはならない宛先を試し、失敗することを確認してください。たまたま通る寛容な経路は正しい方針と同じではないからです。
最後に拠点の識別情報を失効させ、ハブ自身の証明書と他の拠点が動き続ける一方で接続が失敗することを確認します。失効でハブが壊れるなら、役割と識別情報がどこかで共有されていたことになり、それは設計に持ち帰る価値のある発見です。
完成した拠点とは、文書化された識別情報、クライアント専用のプロファイル、ハブ上のピアとネットワークの関連付け、試験済みの戻り経路を持つ拠点です。サーバーファイルの文字を反転させても、そのどれも手に入りません。