OpenVPN のルート上限はどのコンポーネントが本当に持っているのか？

二百本のルートを持つプロファイルが、あるマシンでは動き、別のマシンでは四十本しか入らない。エンジン、それを起動する統合、そしてそれを与えるサーバーのそれぞれに言い分があり、どれも違う地点で一覧を止められる。障害を単一の上限として読むと、間違ったファイルへ案内される。仕組みは三つの段階に分かれており、止まった段階は、何を探すべきか分かれば目に見える痕跡を残す。

三つの段階、三つの異なる上限

まずエンジンがオプションを解析し、このバージョンがそれを理解するかを決める。次に統合がエンジンの報告どおりに導入し、統合自身のコードが一覧を制限したり作り変えたりすることがある。最後にサーバーが、どのクライアント段階も何かを見る前に、特定の識別情報へ何本のルートを配るかを決める。三つの段階、三つの天井、そのうちプロファイルに書かれた数値であるのは一つだけだ。

一つの天井を上げても、他には何の効果もない。配られて拒否されたルートは、サーバー側の方針判断かもしれないし、クライアントが解決した重複かもしれないし、余剰を捨てた導入側の上限かもしれない。どれも直し方が違う。

何かを測る前に三つを切り分けよう。パーサのエラーはトークン名を挙げ、導入側の上限は短いルート表を残し、方針判断は何も残さない。痕跡が、まずどの段階を見るべきかを教えてくれる。

まずパーサが語る

未知のオプションは大きな音を立てて早く失敗し、エラー文がトークン名を挙げるので、これは最も見分けやすい段階だ。正確なメッセージを導入済みのエンジン版と比べよう——ある版で追加されたオプションは、その前の版では未知だからだ。より新しい配備からコピーしたプロファイルが、この不一致のいつもの原因である。パーサは認識しない指示を決して黙って無視しない。

受け入れられたオプションは、結果について何も語らない。解析は成功し、それでも一覧は導入側で切り詰められるか、サーバーが一度も配らないかもしれない。きれいな解析は続行の許可であって、証明ではない。

版の文字列は、実際に動いたバイナリから記録しよう——パッケージ管理者が何を導入済みだと思っているかではなく。この二つは思った以上に食い違う。

導入側にも独自の天井がある

有効化を持つコンポーネントは、エンジンのバイナリではなく NetworkManager のプラグインかもしれず、トンネルが一本もできる前に独自の上限を課すことがある。そのエディタが、動作中のエンジンが決して読まない項目を見せたり、エディタが表示しない項目を読んだりする。どちらの状況も外から見ればクライアントの不具合に見える。どちらもプロファイルの編集では直らない。

設定した数ではなく、届いた数を数えよう。ip route show dev tun0 コマンドが一覧にする導入済みのルートを、配られた一覧と比べれば、捨てられたルートと一度も送られなかったルートを分けられる。配送と一致する数なら、疑いはサーバーに戻る。

より大きな数値を強制するためにエンジンのバイナリをシェルで包むと、更新が不透明になり、巻き戻しが当て推量になる。次の読み手から本当の上限も隠してしまう。

何を提示されたかはサーバーが決める

クライアントごとの方針は、送信前に一覧を縮めることがある。クライアント固有のファイルが一つの識別情報にルートを追加したり、グループ方針がそれらを省いたりして、クライアントは除外されたルートと、一度も定義されなかったルートを区別できない。この曖昧さこそ、サーバー側の記録が重要な理由だ。テンプレートではなく、その識別情報の実際の配送一覧を求めよう。

サーバーの記録と受信した一覧を比べよう。両者の差が方針の層であり、たいていはプロファイルが示すより小さい。

設計が許すなら、連続するネットワークをまとめ、古い項目を削除しよう。数が少なく大きなルートのほうが、高い天井より多くの事例を解決する。

数値は正しい場所で変える

上限を本当に持つコンポーネントの文書化された設定を使おう。プラグインにその項目がないなら、プラグインが機能より古いのか、別の基盤がルートを持っているのかを確認する。そのうえで、選んだ値のそばにエンジン、プラグイン、サーバーの版を記録しておく。次の更新が問いを再び開き、そのメモだけが問いを答えられるものにする。

三つのどれかを更新したら必ず再試験しよう。正しい場所で上げた上限も、それを適用するコンポーネントが変われば動く。版の記録だけが、その動きを予測可能にする。