送信元 NAT は後段のファイアウォールからクライアントのアドレスを隠す

スタッフとラボのクライアント向けに書いたルールを新しいエッジファイアウォールに置くと、それは何にも一致しないか、すべてに一致してしまう。原因は上流にある。ゲートウェイがすでにクライアントのアドレスを書き換えているため、ルールには二つのグループではなく一つの通過アドレスしか見えない。機器を追加しても、経路が失った情報は戻らない。ポリシーを書く前に、区別がまだ存在する最後の地点を特定しよう。

エッジのルールが一つのアドレスしか見ない理由

多対一の変換は、内部のアドレスとポートの組をそれぞれ、割り当てられたポートを持つ共通の外部アドレスに対応づける。会話はそのポート結合によって変換側では区別できるが、単純な送信元プレフィックスの照合を行う下流の機器には共通アドレスしか見えない。それだけで、ルールの上では二つのグループが同一になる。パケットは届くが、グループ分けは届かない。

図が約束するものではなく、ファイアウォールのインターフェースが実際に観測するものを確認しよう。両者は誰の予想よりも頻繁に食い違う。

最後に適用できる識別点を見つける

適用点から始めて、元のプレフィックスが現れるまで遡る。境界はたいてい二つのコマンドで見つかる。

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

NAT テーブルはどの通信がどのルールで変換されるかを示し、conntrack の一覧は稼働中のフローの元の組と変換後の組を示す。上流のファイアウォールが変換後のアドレスしか見ない場所では、グループ単位の送信元ルールはどう書いても機能しない。経路を前後にたどり、二つのクライアントプレフィックスが区別されたまま残る機器にたどり着こう。内側や外側というラベルを信じるのではなく、各ホップで送信元を記録する。

三つの配置とそれぞれの代償

ポリシーは変換を行うゲートウェイに置ける。そこでは元の送信元がまだ見える。通過が変換ではなくルーティングになるなら上流のファイアウォールにも置けるが、その場合は戻り経路を追加し、送信元の書き換えを外すことになる。あるいは、アドレスではなく識別に基づいて、ユーザーや機器を把握する認証済みの制御で適用することもできる。どの選択にも所有者と失敗の仕方があり、ルールを純粋に送信元アドレスの話に保つのは最初の二つだけだ。

どれを選んでも、ルールはそれが一致するアドレスと一緒に文書化しよう。アドレスの前提が黙って変わったルールは、ルールがないより悪い。通信には一致し続けながら、まったく別のものを守っているからだ。

受け入れ: 許可するクライアントと拒否するクライアント

各グループから一台ずつ、二台のクライアントで試し、それぞれが適用点にどう届くかを記録する。両方の組をルールの結果の隣に残し、証拠が示すのは区別が生き残ったことで、別のファイアウォールの存在ではないようにする。NAT やルーティングを変えたら同じ試験を繰り返す。提示されるアドレスこそが静かに壊れる部分だからだ。人を区別する必要がある場所では認証を維持する。送信元アドレスはポリシーの入力であり、身元の証明ではない。

適用点、観測した送信元、ルールをチケットに書く。そうしなければ、次の技術者が二台目のファイアウォールと同じルールを追加する。