OpenVPNハブ1台と3つのLAN：アドレス計画とirouteファイル

三つのプライベートLANは、どの拠点も他拠点の内部を知らないまま一つのハブで接続でき、設計全体は四つの短い設定判断に支えられている。これを機能させているのは特殊なプロトコル機能ではなく、誰も推測せずに済むアドレス計画と、どの拠点がどのプレフィックスを持つかをハブに伝えるクライアント別ルートである。どちらかを誤ってもトンネルは起動してしまい、まさにそのせいで障害の原因が分かりにくくなる。

手順は順番どおりに進める。どの手順も前の手順の計画に依存しており、新しい認証局は必要ない。

誰も推測せずに済む計画から始める

設定ファイルに触れる前に、重複しない四つのプレフィックス、すなわちハブ自身のLAN、各拠点のLAN、ローミング中のクライアントに渡すプールを書き出す。重複がないからこそ他的一切が単純であり、範囲が重なればルーティングは最長一致のパズルになって、クライアント別設定をいくら足しても直らない。次に、自分のLANのゲートウェイでない拠点ルーターはリモートルートをまったく別の場所にインストールする必要があるため、各LANのデフォルトゲートウェイがどのマシンかを確認する。最後に、クライアント別ファイルを引く鍵となる認証名で各拠点を識別しておく。

例示の計画ではプールを三つのLANから十分に離している。あなたの計画は異なってよいが、範囲が二つ重ならないことが唯一の絶対条件である。

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

ハブのカーネルに拠点の在り処を伝える

ハブは拠点ごとに、プレフィックスをトンネルデバイスへ送るカーネルルートと、どのクライアントがそのプレフィックスを持つかをirouteエントリでOpenVPNプロセスに伝える、という二つの情報を必要とする。カーネルルートだけでは、デーモンがどのピアに渡すかをまだ決めなければならないため、パケットはトンネルに届いたところで止まる。irouteエントリだけでは、パケットはたどるべきルートのないままカーネルに残る。どちらの行もデーモンが実際に読み込む設定に属するので、他の何かをデバッグする前に確認する価値がある。

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

カーネルを適用点にする場合は、client-to-client を無効のままにしておく。このオプションはピア間のトラフィックをデーモン内部で中継するので便利だが、そのせいで転送ルールがフローを一切見なくなる。以下の説明はすべて、カーネルが拠点間のあらゆるパケットを見ることを前提とする。

各拠点に必要なルートを与える

各拠点には他の拠点とハブのLANへのルートが必要であり、自分が直接接続しているLANへのルートは不要である。リモートプレフィックスは各ルーターに貼り付けるのではなくハブから配布すれば、四つ目の拠点を追加するときも四か所を編集する代わりにクライアント別ファイルを一つ足すだけで済む。クライアント別ファイルはiroute行も持っており、所有権と広告が同じ場所に置かれる。サーバーの権限モデルの下でディレクトリとそのファイルを読めるようにしておかないと、検索はメッセージもなく失敗する。

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

四つ目の拠点も、固有の認証名、所有するプレフィックス、ハブのカーネルルート、irouteエントリ、到達を許可された拠点だけへの広告という同じパターンに従う。

終わりと言う前に両方向で試す

三つのルーターすべてでIPv4転送を有効にし、次に、片方向のテストは誰が予想するよりも頻繁に壊れた戻り経路のまま通ってしまうため、ファイアウォールが意図したフローを両方向で許可することを確認する。拠点間で送信元の変換は不要であり、送信元をそのまま保つことが各拠点の独自ポリシーを要求に適用させる。

ある拠点LANのホストから別の拠点のサービスへ試し、次に方向を逆にして試し、最後に拠点からハブのLANへ試す。この三つの結果はそれぞれ別の証拠であり、どれ一つとして他を意味しない。拠点ルーターが自分のLANのデフォルトゲートウェイでない場合は、実際のゲートウェイにリモートプレフィックスをインストールし、トンネルクライアントがそのLANへ接続を開始する必要があるときはプールも含める。

次の拠点追加はそれを基準に判断されるため、計画、クライアント別ファイル、ファイアウォールルールを一つの文書として記録しておく。

設計が成り立つのは、計画がプレフィックスを一意にし、カーネルルートがパケットを動かし、irouteが所有者を示し、ファイアウォールが何を許可するかを決めるというふうに、各層が一つの役割だけを持つからだ。何かが壊れたときは、その一覧がそのまま確認する順序にもなる。