VPNポートに印を付けても音声通話は優先されない

VPNのUDPポートを高優先として印を付けるのは最もよくある音声QoSの変更ですが、同じトンネルを共有するファイル転送から通話を切り離すことはできません。どちらのフローも同じ暗号化ソケットから出ていきます。印は次のホップにすべてが等しく重要だと伝えるだけで、何も伝えていないのと同じです。通話を守るのは、暗号化前の信頼できる分類と、実際に自分で制御しているキューです。

トンネルは分類したいフローを隠してしまう

暗号化は内部ヘッダーをトンネルごとにひとつの外部ヘッダーへ置き換えます。その結果、音声もバックアップも同じ送信元、宛先、トランスポートポートを示すため、トンネルポートで判定する分類器は 両者を区別できません。何を優先しても、まとめて優先することになります。

送信元アプリケーションが設定したDSCP値は、何かが外側へコピーした場合にだけ残ります。OpenVPN 2.6にはpasstosがあり、IPv4スコープとして文書化されています。IPsecはトンネル境界で独自のコピーやマッピングのポリシーを適用します。この手順がなければ、外側のパケットはトンネルインターフェースが使う既定値で印を付けられ、下流のキューは中に通話があることを決して知りません。

コピーされた印は、クライアントが提供するどの値と同じくらい疑ってかかるべきです。ワークステーションはバックアップ処理のために優先転送を主張できます。だからこそ、信頼境界での受け入れと再マーキングは、印を信じる前に設計へ入れておく必要があります。

優先度が意味を持つのはキューが形成される場所だけ

上り回線が飽和することが、良いコーデックを機械的な声に変える原因であり、埋まるキューはたいていアクセス機器かプロバイダーのバッファーにあります。トンネルと回線のオーバーヘッドを引いた実効速度まで送信経路を整形することが、そのキューを他人のバッファーではなく自分が管理するハードウェアに留めます。

公平なキューイングとアクティブキュー管理は音声クラスがなくても役立ちます。ひとつの大容量フローがバッファーを埋めるのを防ぐからです。LinuxのCAKEは整形、フローごとの公平性、任意のDiffservクラスをひとつのqdiscにまとめます。導入済みのネットワークマネージャーがその設定を管理すべきで、ふたつ目の競合するキュー設定を持つべきではありません。整形がなければ、大容量トラフィックより上位のクラスでも、すでに満杯のバッファーの後ろで待つことになります。

受信側の処理が無意味なわけではありませんが、パケットが受信回線を渡った後に働きます。応答する送信者には影響できますが、上流ですでに使われた遅延を取り戻すことはできないので、緩和策であって保証ではありません。

公衆インターネットで何が残るか

Diffservアーキテクチャは管理ドメイン内部の扱いを記述しており、だからこそプロバイダーは境界で印を無視したり書き換えたりすることがあります。すべてのネットワークが常に印を削除するという逆の主張も、同じくらい根拠がありません。正直な問いは、この特定の経路が契約上何をすべきとされ、どう監視されているかです。どこかで読んだ規則を繰り返すのではなく、印を付けたプローブで試してください。

プロバイダーがクラスをどう扱うかを尋ね、それから測定してください。保存されてもスケジュールされない印は飾りです。印を見ずにスケジュールする経路は別の問題であり、ふたつには別の修正が必要です。

段階を切り分ける測定計画

制御した競合アップロードとともに通常の通話を一度行い、次に有線回線で繰り返します。通話が何を失ったか、クラスのカウンターが何を記録したか、インターフェースがプランの公称速度ではなく実際の限界にどれだけ近いかを見ます。

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

音声クラスのカウンターがゼロのままなら、分類か印のコピーが壊れており、どれだけ優先しても助けにはなりません。遅延が上がり続けるのにクラスのカウンターがローカルで動くなら、ボトルネックはゲートウェイの先にあります。どちらの結果も、優先度の値を上げて直るものではありません。