ハードウェア NAT オフロードは VPN のルーティング規則を壊すのか

ハードウェア NAT アクセラレーションを有効にすると、VPN の構成が速くなることもあれば、エラーを一切出さないままルーティングポリシーが一部のパケットに適用されなくなることもある。どちらが起きるかは、高速パスが何を飛ばすかで決まり、それはファームウェア、カーネルのバージョン、使われているアクセラレーションの種類によって異なる。設定メニューは、いま有効にしたのがどれなのかをほとんど教えてくれない。

アクセラレータを責める前に、二つの主張を分けておきたい。ルールが適用されなくなったという主張と、カウンタが更新されなくなったという主張である。これは同じ観察ではない。

三つの異なるアクセラレーションが混同される

転送オフロード、暗号アクセラレーション、トンネルのデータチャネルオフロードは別々の仕組みであり、しばしば一つのスイッチを共有している。転送オフロードは確立済みのフローに通常のスタックの一部を飛ばさせ、暗号アクセラレーションは暗号処理を安くし、トンネルオフロードはカプセル化をハードウェアへ移す。通常のルーティングトラフィックを高速化するルータが、トンネルのトラフィックを丸ごと低速パスに残すこともあり、これは性能の結果であってポリシーの変更ではない。逆もあり、トンネルのトラフィックがオフロードされる一方で周囲のポリシーは依然として評価されている。

Linux の flowtable は最も読む価値のある文書化された事例で、確立済みのフローを高速パスに渡せる。その場合、会計と状態の扱いは古典的な転送とは異なり、だからこそカウンタが奇妙に見え始める。

動かなくなったカウンタはほとんど何も証明しない

ルールのカウンタはそのルールを通るパケットを数えるが、オフロードされたフローは最初のパケット以降、二度とそこを通らないかもしれない。するとトラフィックが続いているのに凍りつくカウンタができ、数字を信じるなら迂回とまったく同じに見える。カウンタを眺めることは、フローが数えられている経路を離れたという手がかりとしては今も役に立つ。診断の残りは、パケットが実際にどこへ行くかから導くしかない。

逆の推論も同じくらい失敗する。速いダウンロードは、例外ルールと障害時の扱いがまだ効いていることを示さない。一つのフローを試しているだけで、ポリシーを試しているわけではないからだ。

オフロードがポリシーを壊すかは三つの条件で決まる

第一の条件は、高速パスがポリシーの頼るフックを参照するかどうかである。マークとルートで表現されたポリシーは、パケット単位のフィルタで組んだものより生き残りやすい。第二は、ファームウェアがその組み合わせをそもそも許すかどうかで、トンネルやファイアウォール機能が有効なときオフロードを自動で切るビルドもある。第三は、トラフィックが対象になるかどうかで、アクセラレーションは通常は確立済みのフローに紐づき、断片化したパケットや珍しいパケットを除外することがある。三つすべてが高速化に味方すればポリシーはなお適用され、第一が破綻すればどんな調整でも戻せない。

ルータの型番一般ではなく、いま動かしている組み合わせについてベンダーの文書を読むこと。ファームウェアの版はこうした答えを静かに変える。

測るべきはポリシーであり、スループットではない

どれだけ速いかを測る前に、ポリシーが何を保証すべきかを測る。以下のコマンドは、flowtable が入っているか、コネクション追跡が何を見ているか、クライアントがどのアドレスから出ていくかを示す。変更後に新しい接続で比べること。確立済みの接続は古い経路を保ったままかもしれない。

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

トンネルのトラフィックを覆う flowtable のエントリがあれば高速パスが効いており、コネクションテーブルはフローが想定どおり追跡されているかを示す。アドレスの確認は、ポリシーがインターネットへの出口に関わる場合に出口を裏づけ、ping は到達できるべきプライベートな宛先を裏づける。同じ組み合わせをアクセラレーションを切ってから入れて実行し、時間ではなく結果を比べる。

元の設定を記録して、実験を巻き戻せるようにしておく。どこでもオフロードを切れという一般論は回避策であって、発見ではない。