OpenVPN のルートはどこに置くべきか: クライアントかサーバーか
サーバー設定にむき出しのルートを書いても変わるのはサーバーで、クライアントではない。クライアントのファイル、全体への push、個別クライアントへの push から選び、何が届いたかを確認する。
サーバー設定に route 10.60.0.0 255.255.255.0 を追加し、再起動し、ノート PC を再接続しても、そのサブネットにはそのノート PC からまだ到達できません。行は受け付けられ、サービスはきれいに起動し、ログにもおかしな点はありません。起きたのは、編集したマシン上にルートがインストールされたことで、ゲートウェイはそのプレフィックスに到達できると信じるようになり、クライアントには何も伝わっていません。問題は置き場所そのものであり、同じ行が住める場所は四つあります。
四つの場所と、それぞれ誰が受け取るか
ルートは、クライアント自身の設定で追加するか、グローバル push で全クライアントに提供するか、クライアント固有のファイルで一台に提供するか、サーバー自身のルーティングコンテキストに書き込むことができます。
この四つのケースはほぼ同じ構文を使いながら、まったく異なる結果を生みます。最初の三つはクライアントがトンネルに何を送るかに影響し、四つ目はサーバーがネットワークにどう到達するかに影響しますが、これはサーバー自身に経路が必要なときは有用で、配布と取り違えると有害です。
行を書く前に四つのどれが欲しいかを決め、その後で受け取る側を確認してください。
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
むき出しのサーバールートが人を驚かせる理由
サーバー設定は管理者が最初に見る場所であり、そこにあるルート指示は VPN ネットワークについての宣言のように読めます。そうではありません。OpenVPN はそれを、デーモンが動くマシン上へのローカルなルートインストールとして扱いますが、これは ip route で行って後で忘れるのとまったく同じ種類の変更です。
配布にはルートを push する必要があり、push にはクライアントが引き取ることが必要です。引き取ったオプションを無効にして起動したクライアントは、その提供を完全に無視します。サーバーファイルを書き換える前に、このやり取りの両端を確認してください。サーバーのログが文句を言わないのはサーバー側からは提供が送信済みだからで、受け入れられたルートも次の接続でしか有効にならず、いま参加しているセッションでは決して有効になりません。
二つを別の操作として見れば、失敗は謎ではなくなり、サーバーはプレフィックスに到達でき、クライアントは到達できず、両方の文が同時に正しいのです。
クライアント別ファイルと、それが一致する識別子
クライアント固有のファイルは、サーバーが認証した識別子（既定では証明書のコモンネーム）の名前で作られます。デスクトップクライアントのわかりやすい接続名はその値ではなく、一致しないとファイルは決して読まれません。
サーバーが実際に使うディレクトリを確認し、ファイル名が認証された識別子と大文字小文字まで含めて完全に一致することを確認してください。
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/そのファイルの中でもルートは push する必要があり、クライアント別のコンテキストは、そのクライアントのセッションに適用されるオプションの集合であり、ローカルのルーティングテーブルではないからです。そこにむき出しのルートを書いても、グローバルファイルと同じ問題が起きます。
クライアント自身のファイルと、それを管理するツール
クライアントの設定に置いたルートは、そのクライアントが接続するときにインストールされ、切断するときに削除され、静的な宛先には正しいライフサイクルです。
ネットワークマネージャーがプロファイルを管理している場合、そのオプションを一度インポートして自分のコピーを保持することがあります。後からダウンロードしたファイルを編集しても何も変わらず、これが「ルートはあるのに適用されない」のよくある原因です。
ダウンロードしたファイルではなく有効なプロファイルを確認し、マネージャーが表示するインポート済みの設定も確認してください。そのうえで接続し、テキストファイルにルートがあったからトンネルが勝ったと決めつけず、特定のアドレスがどの経路を使うかをシステムに尋ねてください。
クライアントで確認し、次に戻り経路を確認する
宛先についてはサーバーではなくクライアント自身のルーティングテーブルに尋ねてください。プレフィックス内の一台のホストを引くだけで、使われるインターフェースと次のホップがわかります。
ip route get 10.60.0.10参照先がトンネルを指していれば、配布は機能しており、残る問題は別の場所にあります。既定ゲートウェイを指していれば、ルートはインストールされていないか、クライアント側のオプションで除外されたか、クライアントが使っていないプロファイルのものです。
配布が機能したのに何も応答しないと仮定したら、ゲートウェイの転送、相手側の戻りルート、その間のファイアウォールを確認してください。ルートは経路を選ぶだけで、アクセスを許可するものではありません。