ifconfig-push：net30 のピアアドレスか、subnet のネットマスクか

ifconfig-push の二番目の引数は、net30 ではピアアドレス、topology subnet ではネットマスクです。CCD ファイルを編集する前に、実行中のトポロジを比較してください。

動的クライアントは接続でき、ルーティングも正常に機能しますが、固定アドレスを持つただ一台のクライアントがサーバーにまったく到達できません。ファイアウォールには何の変更もなく、CCD の行ももっともらしく見えます。よくある原因は、サーバーが実行している TUN トポロジとは異なるトポロジ向けに書かれた第二引数です。障害は静かで、クライアントはアドレスを取得して起動し、サーバーは接続を受け入れますが、トラフィックは一切流れません。

net30 ではそのフィールドはピアアドレスで、subnet ではネットマスクです。二つの形式は選択肢であり、決して連続したものではありません。

二つの形式を並べて比較

従来の net30 展開では、各クライアントが、ネットワークアドレス、使用可能なアドレス二つ、ブロードキャストアドレスからなる /30 ブロックを一つ占有します。ifconfig-push はクライアントアドレスとピアアドレスを受け取り、ピアは同じブロック内のもう一つの使用可能なアドレスで、ポイントツーポイントリンクのサーバー側が使用します。

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

topology subnet では、クライアントはサーバーと一つのサブネットを共有し、同じディレクティブがアドレスとネットマスクを受け取ります。サーバー自身のアドレスは server ディレクティブから取得され、二番目のフィールドからではありません。 形式を混在させると、クライアントは自分がポイントツーポイントリンク上にいると信じますが、サーバーはそれをサブネットのホストとしてルーティングします、あるいはその逆です。そのため、ネットマスクを net30 と組み合わせてはいけません。

ブロック内の二行はどちらも CCD ファイル用の単一行です。各クライアントはそのうちの正確に一行を取得します。

サーバーが実際に実行しているトポロジを読む

パッケージの既定値ではなく、何年も前に設定されてそのままコピーされた可能性のある実行中の設定を読みます。topology subnet の有無を探し、次に server 行がアドレスをどう割り当てるかを確認します。トポロジに一切触れていない設定は、subnet を設定している設定とは同じではありません。

次に、クライアントが受け取った設定を読みます。報告されるアドレス、マスク、ピアを見れば、サーバーがどちらの解釈を適用したかがわかります。

固定アドレスを動的プールの外に置く

固定アドレスは、二台のクライアントに同じアドレスが割り当てられないよう、動的プールの外に置く必要があります。subnet トポロジでは、server 行の nopool が自動プールを抑止し、明示的な ifconfig-pool 範囲が動的クライアントの受け取る範囲を定義します。

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

サーバーは 10.99.0.1 を自分に割り当て、固定クライアントアドレスはプール範囲の外にあります。CCD ファイルはプロファイルファイル名ではなく、有効なクライアント ID にちなんで命名され、追加の拡張子は付きません。username-as-common-name が有効なら、認証済みユーザー名が照合すべき ID です。一つの ID を共有する二台のデバイスは固定アドレスも共有しますが、これはルーティングではなくポリシーの問題です。

クライアントが実際に受け取った割り当てを確認する

ほかの何かを確認する前に、目的のクライアントを再接続し、どの CCD ファイルが選択されたかを確かめます。次にアドレス、マスクまたはピア、そしてサーバーへの戻り経路を確認します。subnet 展開でピアアドレスを表示しているクライアントは、まだ間違った形式を使っています。

トポロジの変更はすべてのクライアントとすべての上書きに影響するため、一台のクライアントの修理ではなく移行として扱います。すでに使われているトポロジに合わせて静的行を修正する方が、通常は小さな変更です。 server-options リファレンス はヘルパーとクライアント固有の上書きを文書化しています。

関連記事