仮想 pfSense TAP ブリッジ：フレームが死ぬ三つの地点

LAN インターフェースのルールを無効にしてもフレームは消えたままで、pfSense が自分のファイアウォールを無視しているという結論に至ります。実際に起きているのは別の所有者が判断したということで、それはブリッジ自体、メンバーインターフェース、またはゲストの外にある仮想スイッチです。それぞれに独自の制御と独自のログがあります。

以下の三つの境界は、設定を変える前に切り分ける価値があります、一方を無効にしても他方を補えないからです。

一つのフレーム、三つのポリシー所有者

TAP クライアントのフレームはトンネルデバイスから入り、pfSense のブリッジを渡り、LAN メンバーから出て、何かに到達する前に仮想スイッチを通ります。ゲストの内部では、フィルタリングはブリッジでもメンバーインターフェースでも起こり得て、どちらが有効かは固定の性質ではなく設定の選択です。ゲストの外部では、ハイパーバイザーがその仮想アダプターに自分が持たない送信元 MAC のフレームを送らせてよいかを決めます。どの地点でのドロップもクライアントから見れば同じに見えます。

調査の前に想定経路を書き留めてください、トンネルメンバー、ブリッジ、LAN メンバー、仮想スイッチ、宛先です。そのうえで、その経路上のどの所有者がフレームを見たはずかを問います。

どの pfSense の制御がフィルタしているか

pfSense はこのために二つの sysctl を文書化しており、一つはブリッジメンバー上でのフィルタリング、もう一つはブリッジ自体でのフィルタリングで、少なくとも一方は有効のままにする必要があります。ブリッジレベルのフィルタリングはブリッジメンバー経由で到着する通信に適用されるため、対称ではなく向きとしては受信側です。実際にフィルタしているインターフェースのルールを読んでください、フィルタの役割を持たないメンバーに設定したルールは何もしません。 ブリッジフィルタリングのドキュメントが所有関係を明示しています。

IP アドレスを持たないメンバーインターフェースには独自のアドレスやサブネットのマクロがないため、そのマクロに対して書いたルールは意図した LAN 以外を表すことがあります。便宜的なマクロではなく、意図して割り当てたネットワークオブジェクトを使ってください。

フラグメントはフレームではない

イーサネットフレームは IP パケットを運び、IP パケットはより大きなデータグラムのフラグメントになり得るので、この二つの語は交換できません。トンネルの内側には内側パケット、外側には外側のトランスポートパケットがあり、障害はどちらに属することもあります。小さな ping はそのスタックを通る一つの経路を試すだけで、大きな転送について何も証明しません。 隣接する二つの境界で失敗するやり取りを比較し、ルールを疑う前にドロップの理由を読んでください。

フラグメントが消えるなら、答えは範囲を限定した修正かパケットサイズの調査であり、フィルタリングを全面的に無効にする決定ではありません。

ハイパーバイザーにも独自の受け入れ判断がある

他のマシンのために通信をブリッジするゲストは、自分のアダプターのものではない送信元 MAC アドレスを持つフレームを送信し、多くの仮想スイッチはポートグループが許さない限りそれをなりすましと見なします。その送信を許可することと、アダプターにあらゆるフレームの受信を許可することは別の制御であり、両方をどこでも有効にするのは問題が必要とするよりはるかに大きな変更です。ブリッジが受信すべきフレームと送信すべきフレームを洗い出し、それを所有する境界でその振る舞いだけを許可してください。遠隔で管理するブリッジを変更する前に、コンソールアクセスを確保しておいてください。

接続を回復することは試験の半分であり、残りの半分は、遮断されたままであるべきフローが今も遮断されていることを確認することです。

どの所有者がフィルタし、どの制御を変え、どの二つのフローを検証したかを記録してください。その記録があれば、次のインシデントが pfSense は自分を無視しているという同じ推測から始まることはありません。