OpenVPN が古いルートを配り続ける？読み込んだ内容を確認する

ルートを追加し、サービスを再起動し、再接続しても、クライアントのテーブルは以前とまったく同じに見えます。サーバーが編集を読み込んでいないか、クライアントが受け取ったものをインストールしていないか、二つの異なる可能性があります。症状以外に共通点はありませんから、最初の一歩はどちらなのかを突き止めることです。

以下の比較がプロセスから外側へ進むのは、どのファイルが有効かを決めるのはプロセスだけだからです。

編集したファイルとプロセスが読むファイル

unit とそれが生成したコマンドラインから始めます。systemd のホストでは、systemctl cat openvpn@server が ExecStart 行を出力し、インスタンス unit は通常インスタンス名から設定パスを導くため、openvpn@office として起動したデーモンは openvpn@server として起動したものとは別のファイルを読みます。それを実行中プロセスの argv と比べます。構成管理ツールは変更を失う別の道も加え、正しいファイルを unit が一度も挙げない場所に書き込むため、成功したデプロイが何もしていないように見えます。

タイムスタンプを見れば、ファイルがプロセスの起動時刻より新しければプロセスはそれを読めていないとすぐに分かります。ルーターのファームウェアは三つ目のケースを加え、多くの機種が設定をフラッシュに保持して起動時に組み直すため、ディスク上のファイル編集はまったく違う層になります。

サーバーが配るものとクライアントが入れるもの

配信されたルートは二つのフィルターを通る必要があります。サーバー側では、コメントアウトされたブロックや名前が一致しないクライアント専用ファイルではなく、読み込まれた設定に置かれている必要があります。クライアント側では pull が有効で、どの pull-filter もそのオプションを捨てていないことが必要です。verbosity 4 で接続してクライアントが報告する配信オプションを読み、ルートがその一覧にあればサーバーは務めを果たしており、インストールしないのはクライアントの選択です。

クライアント専用ファイルは混乱のよくある元です。証明書の common name にちなんで名付けたファイルはそのクライアントだけにオプションを配り、一文字の食い違いで配信は静かに止まり、どちら側にもエラーは出ません。サーバーは接続時に見た common name を記録しますから、その値をクライアント名だと思っているものではなく、ファイル名と比べてください。

配信されたプレフィックスと戻りの経路は別の問題

redirect-gateway を意図的に無視してローカルのインターネット経路を保つクライアントは、二つ目の無関係な穴を作ります。サーバーの探査はトンネルのアドレスに届きますが、応答が決して届かないのは、サーバーのトンネル IP 宛ての応答がクライアントの通常のデフォルトゲートウェイで経路選択されるためです。ここで悪いのは配信されたサブネット経路ではなく、欠けているのはサーバーのトンネル網宛ての通信をトンネルデバイスへ戻す経路です。

クライアントにその経路を足すと、サーバー起点の探査への応答が直ります。配信されたサブネット経路の代わりにはならず、逆もまた同じで、二つは逆方向の通信を表しているからです。

両端のテーブルを比べる

変更したら再接続し、クライアントのテーブルで配信されたプレフィックスとトンネルデバイスを読みます。次に、クライアントから配信サブネット上のホストへ、そのホストからクライアントへ戻すという両方向で試します。経路はあるのに通信が流れないなら、向こう側が転送していない、ファイアウォールが通信を落としている、応答に戻り道がない、のいずれかです。

三つの識別子、つまり設定パス、unit またはインスタンス名、試したクライアントの識別情報を一緒に残します。

この三つがあれば、次に起きたときは再調査ではなく五分の確認で済み、トンネルが他人の担当になったとき同僚に必要なのもこの三つです。

再起動を生き延びるルートの問題は多くの場合ルーティングの問題ですらなく、不具合は読み続けているテーブルより上流にあります。