OPNsense 背後の OpenVPN クライアント固定アドレス

名前には動かないアドレスが必要だが、OpenVPN の pool ファイルはアドレスを粘着させるだけだ。そのファイルを失うか、別のコモンネームで証明書を再発行すると、戻ってきたクライアントは pool の別の場所に着地し、その DNS レコードは依然として古いアドレスを指している。恒久的な答えは、アドレスを固定するクライアント固有の上書きと、固定したアドレスが動的範囲の外に収まるようにする広めのトンネルネットワークだ。その拡張の背後にある計算こそが、混乱のほとんどが住む場所だ。

OPNsense はこれらの上書きをサーバーのクライアント固有設定に保持し、証明書のコモンネームをキーにするため、コモンネームはアドレス計画の一部になる。

粘着リースは固定アドレスではない

pool ファイルはアドレスとクライアントの対応を書き込み、既知のクライアントが再接続するとそれを返す。これは契約ではなく利便性であり、ファイルは再生成でき、クライアントの身元が変われば対応は消え、同じ pool を共有する二つのサーバーはそれについて合意しない。クライアント固有の上書きは、アドレスが履歴ではなく設定から来るため、別の仕組みで動く。上書きが他の設定と一緒にバックアップされていれば、アプライアンスの再起動や再インストールにも耐える。

動的な代替案、つまり client-connect スクリプトと動的更新で VPN を DNS に配線する方法は動作するが、更新を受け付けるリゾルバーと、接続のたびに走るスクリプトが必要だ。アプライアンスではベンダーが提供するパッケージに限られるので、通常はそこでその計画は止まる。

誰も楽しめない /30 の計算

既定の net30 トポロジーでは各クライアントが独自の /30 を受け取り、最初の使用可能アドレスはサーバー側に、二番目はクライアントに割り当てられる。したがって上書きはサーバーの動的トンネルネットワークの外に置く必要があり、そのためにはまずそのネットワークを広げる。10.8.0.0/24 のサーバーは 10.8.0.0/23 に移れ、古い範囲の半分を動的クライアントに、もう半分を上書きに残せる。元の /24 を追加の IPv4 ローカルネットワークとして加え、両方の半分への通信がトンネルに入るようにする。

各上書きアドレスは /30 の境界に落ちる必要があるため、最後のオクテットは四の倍数になる。10.8.1.0 の /30 はクライアントに 10.8.1.2 を与え、DNS レコードが運ぶのはそのアドレスだ。代わりに 10.8.1.3 を選ぶと、そのアドレスがトポロジーに一度も割り当てられていないサブネットに属するため、接続はするが通信を通せないクライアントができる。

上書きを広げた範囲の上端から下へ割り当てれば、動的 pool が固定された島の周りではなく空き領域へ広がるため、計画は保ちやすい。

ローカルネットワークとクライアントが問い合わせるゾーン

クライアント間の通信には独自の許可が必要だ。サーバーの IPv4 ローカルネットワーク一覧には範囲の両半分、動的と固定の両方を含める必要があり、これがなければサーバーは一方のクライアントからのパケットを受け取っても、他方へ通すことを許すポリシーを持たない。症状は、名前は解決するのに接続はなお失敗するため、DNS の障害のように見える。同時に、ローカルネットワークの項目だけではピア間の転送は有効にならないため、クライアント間の設定も確認する。

レコードは、リモートクライアントが実際に問い合わせるゾーンに公開する。LAN リゾルバーだけが提供するゾーンのレコードは、プッシュされたリゾルバーが別を指すクライアントには見えず、誤ったゾーンにレコードを増やしてもそれは決して直らない。何かを追加する前に プッシュされた DNS オプションと検索ドメインを確認する。

新しい接続で確認すべきこと

クライアントを再接続し、他を試す前に割り当てられたアドレスがその上書きと一致することを確認する。次に二台目のクライアントから名前を解決し、名前でサービスに接続すると、DNS レコード、ルート、ファイアウォールをまとめて試すことになる。名前が解決してもサービスに届かないならそれは命名ではなくルーティングかポリシーの問題なので、サーバー側で戻り経路を確認する。上書きの表を証明書一覧の隣に置き、両方を一緒に見直す。

別のコモンネームで再発行された証明書は、その上書きと一致しなくなり、クライアントを動的 pool に戻す。身元の変更の後にはそれを想定しておく。