openfortivpn が接続するとき、ルートと DNS は誰が所有すべきか

動作中の openfortivpn セッションでは四つの段階が積み重なります。クライアントはゲートウェイで認証して TLS 接続を開始し、次にその接続の中で PPP を実行し、次にアドレスと DNS 情報を受け取り、最後にホストルートとリゾルバ設定を適用します。各段階は次が生きていなくても生きていることがあり、だからこそ「接続済み」はサポートスレッドでこんなにも滑りやすい言葉なのです。

混乱のほとんどを取り除く決定は、最後の段階を誰が所有するかです。VPN クライアントがホストの変更を自分で適用するか、別のコンポーネントが行うかであり、両方を中途半端に混ぜると、ルートとリゾルバファイルが別々のセッションを表すことになります。

一つの接続に見える四つの段階

最初の段階は受け入れです。 名前付き認証ドメイン またはワンタイムコードを経て、続行に必要なパラメータを受け取ります。クライアントがゲートウェイに接続したと出力したとき、それは TLS トランスポートが上がっていることを意味します。PPP がネゴシエートしたという意味ではなく、まして内部アプリケーションに到達できるという意味でもありません。

第二の段階は PPP リンクです。クライアントはトンネルデバイスに対して PPP プロセスを起動し、双方がリンクオプションとアドレスをネゴシエートします。その後に初めてホストはセッションが使うローカルアドレスとリモートアドレスを知り、そのとき初めてトンネルへ向かうルートが意味を持ちます。

第三の段階はその情報をホストに適用することで、ここで所有権が重要になります。クライアントはルートを追加してリゾルバ設定を書き換えることも、身を引いて両方をそのマシンのネットワークを管理する何かに任せることもできます。プロジェクトの README はこれらを一つの自動動作ではなく別々の責務として説明しています。

誰がルーティングテーブルを編集するか

既定ではクライアントが所有者です。物理インターフェース経由でゲートウェイへのルート、トンネルのピア用のルート、セッションが使用を許可されたネットワーク用のルートを追加し、プロセス終了時にそれらを削除します。この既定は、ネットワークマネージャが一つだけで他の VPN ソフトウェアがないノート PC では便利です。

引き渡しを選ぶのは、他の何かが本当にルーティングを所有している場合だけです。ネットワークマネージャとの統合、コンテナのネットワーク名前空間、サイト全体のルーティングエージェントは、同じプレフィックスを導入して片付ける方法をすでに知っているかもしれません。その場合に no-routes オプションを渡すと、二人の書き手が同じテーブルを奪い合うのを防げます。これはきれいな失敗ではなく、一つのサブネットが断続的に失われる形で現れる競合です。

重複は引き渡す第二の理由です。プッシュされたルートにローカルネットワークがすでに使っているプレフィックスが含まれている場合、クライアントはその競合をあなたの代わりに解決できません。そのプレフィックスがトンネル経由か、物理リンク経由か、より具体的なルート経由で到達できるかを誰かが決める必要があり、その判断はトポロジを所有する人に属します。

後片付けが第三です。ルートを削除する前にクラッシュしたクライアントは、セッションより長く生きるブラックホールを残し、次の接続がその上に重複を追加するかもしれません。ルーティングを所有する者は、古いエントリが消えたことの確認も所有します。その確認を起動経路の一部にし、任意の後片付け手順にしないでください。

誰が DNS とリゾルバファイルを所有するか

DNS は同じ決定で、縁がより鋭いだけです。クライアントはゲートウェイまたは PPP ピアが報告する DNS サーバーを受け入れ、ホストのリゾルバ設定に書き込めます。単純なマシンではそれがまさに望むことで、内部名はトンネルが上がっている間だけ解決されます。

現代の Linux ホストではリゾルバがローカル stub に管理されていることがあり、その stub の背後でリゾルバファイルを書き換えると、正しく見えるのに一貫しない動作をする設定になります。ホストがすでにリゾルバマネージャを実行しているなら、DNS はそれに所有させ、サポートされたインターフェース経由でトンネルのサーバーを渡してください。クライアントの no-dns オプションはそこでは正しい選択であり、回避策ではありません。

分割 DNS は、誰がファイルを書くかとは別の問いです。すべてのクエリをトンネル経由で送るのは単純で遅い方法です。内部ゾーンだけをトンネル経由で送るには、ほとんどの単純なクライアントが提供しないドメインごとの設定が必要です。クライアントのリゾルバ変更を有効にする前に、ホストがどの動作を必要とするかを決めてください。ここでの誤った選択は、トンネル自体が正常でも名前解決の停止のように見えます。

権限、準備状態、そして引き渡し

トンネルデバイスの作成とホストルートやリゾルバ状態の編集には昇格したネットワーク権限が必要です。よくある間違いは、だからといってブラウザやトンネルを使うアプリケーションまで含めてすべてを root で動かすべきだと結論づけることです。特権部分は小さく保ってください。クライアントとその設定ファイルは管理者が所有し、ユーザーアプリケーションは通常のアカウントのままにします。

準備状態は消費者ごとに定義すべきです。スーパーバイザはクライアントプロセスが動きトンネルデバイスが存在するときにサービス開始と見なせます。バックアップジョブは、そのストレージエンドポイントがトンネル経由で応答したときに初めて VPN を使用可能と見なすべきです。これらは異なる確認であり、弱い方を強い目的に使うと、早すぎる開始と断続的な失敗を生みます。選んだ定義を書き留めてください。準備状態について意見が合わないスーパーバイザとジョブは、起こるのを待っているサポートチケットです。

四つの観察で契約を試してください。ゲートウェイ段階が完了し、PPP がアドレスを割り当て、意図したルートが存在し、内部ホストへの要求が成功する。その後クライアントを停止し、それらすべてが削除または復元されたことを確認します。トンネルが閉じた後もホストが内部名を解決したりルートを保持したりするなら、所有権の引き渡しは不完全です。