OpenVPN トラフィックを整形する：どのインターフェースが見るのか

何を制限したいのか、それを識別する情報をどのパケットが運ぶのか、整形器はどのインターフェースを見られるのか、暗号化中にルーターが耐えられるのはどこまでか、という四つの確認を順に行う。ルーターには OpenVPN ページと帯域幅ページの両方が付いてくるが、両者が共存していることはどちらについても何も証明しない。順序が重要で、間違ったパケットに対して書かれたルールは、そのレートがどれほど正しくても決して一致しない。

目標から始める。単一デバイスの上限、容量の公平な共有、一つのアプリケーションへの優先度のいずれかであり、それぞれ異なるマッチが必要だ。

ルールより先に目標を名づける

デバイスごとの上限には、そのデバイスのアドレスへのマッチが要るが、そのアドレスはトンネルの内側にしか存在しない。競合するフロー間の公平性には、すべてが共有するキューが必要で、ホストごとのルールではない。アプリ優先度にはアプリケーションを識別する何かが必要で、暗号化が内部ヘッダーを視界から消した後では三つの中で最も難しい。目標を先に書き留めれば、どの事実が必要で、どこで入手できるかが分かる。

直接の WAN トラフィックで機能する上限は、同じホストがトンネル内で対象になっている証拠にはならない。ルールは、整形器が見るヘッダーに決して現れないアドレスにマッチしているかもしれない。

トンネルの内側か外側か

ルーターが持つ VPN クライアントでは、多くの LAN フローが一つの暗号化トランスポートの中を通る。カプセル化の前なら、ルーターは内部の送信元と宛先をまだ見ているので、その段階に付けたポリシーはデバイスごとに分類できる。カプセル化の後では、通常の機器は 外側の接続 しか見えず、VPN ポートへのマッチはどのデバイスが責任を持つかを何も語らない。その一つの事実が、ルールの置き場所を決める。

プラットフォームによって公開の仕方は異なる。トンネルインターフェース上でキューイングと分類を行う整形器を提供するものもあれば、リミッターを VPN と非 VPN のトラフィックで同じように振る舞うインターフェースルールとして扱うものもあり、異なる能力で両方を備えるものもある。他のベンダーのガイドからインターフェース名をコピーするのではなく、対応するインターフェースについてファームウェア自身のドキュメントを読むこと。

アドレスがどこで利用可能なままか、変換がどこで起きるか、どのキューが実際にボトルネックを制御しているかを見極める。

三つのポリシー、三種類の証拠

レート上限は、制限されたデバイスからの持続的な転送を、別のデバイスが同時に転送している状態で示すことで証明される。公平な共有は、一方が飢えるのではなく二つのフローが同程度のレートに達することで証明され、これは別の測定である。アプリ優先度は、大容量転送中も対話的なタスクが応答し続けることと、分類器がそもそもフローを認識したかどうかを確認することで証明される。各ポリシーには独自の観察が必要で、どれも設定ページでは証明されない。

分類には特に疑いの目を向けるべきだ。外側の暗号化ポートへのマッチでは、内部の各アプリケーションの識別情報を復元できない。したがって、一つのアプリを優先しているように見えるルールが、実際にはそのトンネルからのすべてを優先している可能性があるため、ルールの意図ではなくカウンターを読むこと。

暗号化された負荷を測るのであって、素の負荷ではない

整形、分類、暗号化は一つの CPU を奪い合い、ハードウェアアクセラレーションは、あなたが監視しているまさにそのルールとカウンターを迂回させることがある。単純なルーティングテストのスループット値は、暗号化され整形された負荷の下での筐体についてほとんど語らない。両方向、複数の代表的なクライアント、そして大容量転送と並行した小さな対話的タスクを試すこと。負荷時の応答性は、アイドルリンクのピーク値より重要である。

測定には、トンネルを迂回すべきトラフィック、両方が関与するなら両方のアドレスファミリー、そしてトンネルが落ちたときに何が起きるかを含める。トンネルが健全な間だけまともな振る舞いをするポリシーは、半分のポリシーでしかない。

仕様は、トラフィックのマッチ、適用点、測定した負荷の三行で書く。OpenVPN と QoS は仕様ではない。