Mac VPNのバイトカウンターが証明することと、証明しないこと

クライアントのステータスウィンドウを開くと、バイトが増えてトンネルも接続済みで、数字は安心に見えます。ウィンドウを閉じてもオフィスアプリは失敗したままで、カウンターは誰も尋ねていない質問に答えていたことになります。インターフェースでバイトを数えることは、その観測点のトラフィックを測るだけです。見ている数字から、それが報告する層へ、そしてアプリが実際に返した結果へと進んでください。

数字を選ぶ前にインターフェースを選ぶ

数字が表示されている場所から始め、その横のラベルを読みます。クライアントのウィンドウはセッション合計を、トンネルインターフェースは内側のIPバイトを、物理アダプターは暗号化された外側のバイトを示すことがあり、いずれも偶然バイトで表された三つの異なるカウンターです。コマンドラインでは、netstat -ibn が各インターフェースのアドレスごとに一行を出力するため、トンネルが複数回現れることがあります。その行をクライアントが実際に持つインターフェースと照合し、宛先が選ぶルートで確認します。utun という名前のデバイスは、VPNのものでも、別のトンネルのものでも、気にしない何かでもあり得ます。

読みやすいという理由だけでWi-Fiのカウンターに置き換えないでください。別の観測点は別の問いに答えます。

差分を取り、起動からの累計は使わない

行を読み、小さな許可済みのリクエストを一度行い、同じ行をもう一度読みます。その差分が証拠で、起動からの累計にはマシンが行ったすべてが含まれるからです。間隔を短く保てば、バックグラウンドのトラフィックが混入する機会は少なくなります。忙しいマシンでは、nettop がスループットをプロセスに割り当てられるので、インターフェースのカウンターに戻る前に範囲を絞れます。

差分がきれいではないことを受け入れてください。メール、更新、クライアント自身のキープアライブがすべて寄与するので、数字は測定値ではなく上限として扱います。間隔の間にアプリ以外を何もしていなければ、上限は通常、役立つ程度に引き締まっています。

内側と外側のカウンターは別のものを測る

物理アダプターは外側のヘッダーを含む暗号化パケットを数え、トンネルインターフェースは受け取る、または渡すペイロードを計上します。両方を足すと同じ転送を二重に数えます。オーバーヘッド、再送、カプセル化も、単純な等式を不可能にします。

二つのカウンターが逆方向に動くのは矛盾ではなく、発見です。通常は、トラフィックがある層に入って、別の層からは出なかったことを意味します。

カウンターをアプリの結果と組み合わせる

受信合計はプロトコルのやり取りで増えても、望んだサービスは依然として失敗することがあります。送信の増加はさらに語らず、カーネルがパケットを受け取ったことの証明であって、何かが応答したことの証明ではありません。

カウンターの横に、名前解決の失敗、接続のタイムアウト、TLSの拒否、HTTP応答の到着という正確な結果を記録します。これは四つの異なる障害で、トンネルに関わるのはそのうち一つだけです。証拠をもっと先へ進める必要があるなら、次の観測点はゲートウェイかサービスの境界で、リクエストが届いたかどうかをそこで確認できます。Macのネットワーク設定をリセットすると、測っていた状態が壊れるだけで何も分かりません。

次の人に必要なメモを書く

インターフェース名、カウンターのラベル、間隔、前後の値、そしてアプリの結果です。これだけあれば、同僚はあなたの午後を繰り返さずに観測を再現できます。カウンターの意味はリリース間で変わり得るので、クライアントのバージョンとmacOSのバージョンも加えます。

パケットキャプチャ全体とシステムダンプは省きます。一つのリクエストの間にどのローカルカウンターが動いたかを説明するのに、これらが必要になることはめったにありませんし、レポートを読む人を遅くします。クライアントが独自の統計を表示するなら、自分のラベルに翻訳するのではなく、そのラベルをそのまま引用します。メモの目的は、何を測ったかを記録することで、それが何を意味するかを論じることではありません。