境界FWの四つの領域

社内端末から外部Webへ接続でき、外部からDMZのWebにも接続できる一方、管理用SSHは外部から拒否したい。この条件を満たすには、FWのACL、接続状態の追跡、NAT・NAPTをどの順で確認すればよいでしょうか。この記事では一台の境界FWを通る二つの通信を最初のパケットから応答まで追います。

科目B（午後）では『443番なので許可』『NATしているので安全』では不十分です。送信元・宛先・ポート・方向・状態・変換前後の値、ルール評価の位置を揃えて判断します。後半では設定ミス、非対称経路、IPv6、状態テーブル障害、事故後の復旧を扱います。以下のIPアドレス、時刻、ルール、ログは教材用の架空例です。

1. 構成と用語を最初に固定する

社内LANは10.10.1.0/24、社員端末は10.10.1.24、DMZのWebサーバは10.10.20.10:443、管理ネットワークは10.10.99.0/24です。境界FWは外向きアドレス198.51.100.10を送信側NAPTに使い、公開Web用アドレス198.51.100.20:443をDMZへ転送します。外部Webは203.0.113.80:443とします。

用語	意味とこの事例での役割
FW（ファイアウォール）	ネットワークやホストの境界で通信を許可・拒否する装置又はソフトウェア。この例の境界FWはLAN、DMZ、管理ネットワーク、WANの間のパケットを評価する。FWという名称だけではTLS本文の検査や利用者認証まで実施するとは限らない。
ACL（アクセス制御リスト）	送信元・宛先IP、プロトコル、ポート、方向、インターフェース、状態などの条件と動作を並べたルール群。一般的な先頭一致方式では広い許可を上に置くと、下の拒否が到達不能になる。製品の評価順を確認する。
ステートフルインスペクション	許可した通信の方向・両端IPとポート・プロトコル・タイマー・TCP状態などを追跡し、その通信に属する応答を認識する方式。すべての戻りパケットを無条件に通す意味ではない。
コネクション追跡（conntrack）	FWが通信状態を保持する仕組み。この例のTCP通信では最初のSYNと応答方向を識別し、途中のパケットを既存フローへ関連付ける。UDPでも一定時間の疑似的な状態を持つ実装がある。
NAT	パケットのIPアドレスを変換する総称。基本的な1対1のアドレス変換と、ポートも使って複数端末を同一公開IPへ写すNAPTを区別する。変換という機能自体は許可・拒否ポリシーではない。
NAPT（PAT）	IPアドレスとTCP/UDPポートを組で変換する方式。10.10.1.24:51544を198.51.100.10:40001へ写し、戻りを元端末へ戻す。公開IPが一つでも、異なる外向きポートを使って複数の内部通信を区別できる。
SNATとDNAT	SNATは送信元を変える。この例の外向きNAPTがSNATに当たる。DNATは宛先を変える。198.51.100.20:443宛てを10.10.20.10:443へ送る公開設定がDNATに当たる。
五つ組	送信元IP・送信元ポート・宛先IP・宛先ポート・プロトコルをまとめた呼び方。方向、インターフェース、変換前後の値も実際の調査には必要。

ここではLinux netfilterに近い概念順序を例に、公開通信のDNATを転送フィルタより前、送信側SNATを転送フィルタより後に置きます。商用FWでは画面上のルールが変換前・変換後のどちらを参照するか異なります。設問中の仕様や実機の処理順を優先します。

境界FWの四つの領域

1. 社内から外へ
2. 管理網からDMZへ
3. NAPT後に送出
4. DNAT後に転送

WANへ出る社内通信と、WANからDMZへの公開通信を同じFWで分ける。

図の管理端末は10.10.99.0/24にあり、DMZのSSHへ接続する用途です。WANからDMZのSSHを許可する意味ではありません。またDMZ Webへの公開通信は外部クライアントからFWへ入り、図の右側へ転送されます。矢印は送信側の経路を整理したもので、応答も同じFWで処理する設計です。

2. ACLの条件と評価順を読む

次は概念的なルール表です。実製品の設定コマンドではありません。例のFWは上から評価し、最初に一致した規則を適用します。DNAT後の転送フィルタでは、公開Webの宛先は10.10.20.10:443として評価する、とこの構成で定義します。

優先順	条件と動作
R01	状態INVALIDのパケットを拒否し、理由を記録する。
R02	追跡済みのESTABLISHEDと、必要なRELATED通信を許可する。ただしその状態がどのフローに結び付いたか追跡する。
R10	LAN 10.10.1.0/24→WANのTCP 443、状態NEWを許可する。外向き送信では後段のNAPTを適用する。
R20	WAN→DMZ 10.10.20.10のTCP 443、状態NEWを許可する。198.51.100.20:443へのDNAT後にこの宛先として照合する。
R30	管理網10.10.99.0/24→DMZ 10.10.20.10のTCP 22、状態NEWを許可する。WAN起点のSSHには一致しない。
R99	ほかを拒否し、必要な情報を記録する。存在しない暗黙の許可を期待しない。

R02の『ESTABLISHED』はTCPのアプリ処理が成功したという意味ではありません。実装上の追跡状態であり、戻りのSYN/ACKなどが許可済みフローに対応するかを判断するために使います。SYN/ACKを許可したことと、最終的にTLSやHTTPが成功したことも別です。

ACLフィールド	読解と誤設定の例
方向とゾーン	LAN→WAN、WAN→DMZ、管理網→DMZを混同しない。WAN→DMZのR20をWAN→LANへ広げると、公開対象が拡大する。
送信元・宛先IP	CIDRの広さと変換前後を確認する。10.10.20.10/32を10.10.20.0/24に広げると、DMZ内の別ホストまで到達できる可能性がある。
プロトコル・ポート	TCP 443とUDP 443は別条件。443番でも任意のアプリが動けるため、ポート許可だけでHTTPS通信の正当性を証明しない。
状態	NEWを許す方向と、ESTABLISHEDを返す方向を分ける。状態追跡を無効にしたACLでは戻り通信の明示的な条件が要る。
順序	先頭一致なら広い許可が前にあると後の拒否が効かない。変更前に上位・下位の重複と影響する通信を調べる。
ログの有無	拒否時のrule ID、元の五つ組、変換前後の値をどこまで記録するかは製品設定次第。許可ログを省略した場合、記録がないことは通信がなかった証拠にならない。

ACLとNATを同じ装置に設定しても、それぞれの仕事は別です。R20で許可する条件と、公開IPをDMZ IPへ変える条件の両方がそろって初めて、外部からDMZ Webへ到達できます。逆に、DNAT設定だけを作ってもR99で拒否される構成があります。

3. LANから外部WebへのNAPTと戻り通信

社員端末10.10.1.24は、送信元ポート51544を使って203.0.113.80:443へTCP接続を始めます。FWはR10で最初のSYNを許可し、送出前に送信元を198.51.100.10:40001へ変えます。外部Webは社内の10.10.1.24ではなく、198.51.100.10:40001を接続相手として見ます。

外向きNAPTと応答の復元

論理的な通信経路。実際の送信元・宛先の値は図の下の表で確認する。

段階	送信元→宛先と意味
FW到着前のSYN	10.10.1.24:51544→203.0.113.80:443/TCP。LANから入る新規通信としてR10を評価する。
FW送出後のSYN	198.51.100.10:40001→203.0.113.80:443/TCP。NAPTで送信元IP・ポートが変わる。
FW到着時のSYN/ACK	203.0.113.80:443→198.51.100.10:40001/TCP。記録済みの通信に対応する戻りとして追跡する。
FW転送後のSYN/ACK	203.0.113.80:443→10.10.1.24:51544/TCP。対応表で宛先を元に戻し、社員端末へ届ける。

NAPT対応には少なくとも内部側のIP・ポート、外部側のIP・ポート、プロトコル、相手先、状態や期限が関わります。具体的なマッピングの再利用と戻りパケットのフィルタ条件は製品・プロトコルに依存します。『公開IP:ポートが合うなら、どの外部ホストからのパケットでも必ず通る』とは言えません。

NAPTをしても通信内容は暗号化されません。外向きのHTTPSが秘匿されるのはTLSの性質です。また外部Web側のログには198.51.100.10と40001が残り、社員端末の特定には同時刻のNAPT対応表と認証・端末ログが必要です。公開IPだけで利用者を一意に識別しません。

4. WANからDMZ WebへのDNATと許可

外部クライアント203.0.113.66:57000が198.51.100.20:443へ接続すると、FWは公開先設定に従って宛先を10.10.20.10:443へ変えます。この事例の転送フィルタはDNAT後の宛先でR20を評価し、新規TCP接続を許可します。DMZサーバからの応答は追跡済み状態で戻し、外部へ出る時に送信元を198.51.100.20:443へ戻します。

段階	送信元→宛先とACL上の注意
FW外側に着いたSYN	203.0.113.66:57000→198.51.100.20:443/TCP。外部クライアントが指定した公開アドレス。
DMZへ転送するSYN	203.0.113.66:57000→10.10.20.10:443/TCP。宛先DNAT済み。R20はこの値を照合する事例。
DMZサーバの応答	10.10.20.10:443→203.0.113.66:57000/TCP。元の許可フローへの応答として追跡する。
WANへ出る応答	198.51.100.20:443→203.0.113.66:57000/TCP。公開側から見た接続先と整合するよう逆変換する。

同じ198.51.100.20のTCP 22へ外部から接続しても、この例には対応するDNATもWAN→DMZの許可ルールもありません。R30は管理網からDMZへのSSHだけです。『DMZにSSHがある』ことから『インターネットにSSHが公開されている』と推論してはいけません。

4-1. 変換前後の宛先を取り違えない

別製品のルール画面で198.51.100.20を宛先とするACLを書く場合もあります。ある製品がNAT前の公開IPで評価し、別の製品がNAT後のDMZ IPで評価するなら、同じ記載を写すと予期しない拒否又は公開につながります。パケットキャプチャやヒットカウンタで、適用場所と実際の一致値を確認します。

NATとルーティングも分けて確認します。DNATで宛先をDMZへ変えても、戻りが別の経路でFWを通らなければ、状態表や逆変換が働かない構成があります。冗長FWを切り替える場合は状態・NAT対応の同期方法を確認し、既存接続の継続が必要か、新規接続で復旧してよいか決めます。

5. ステートフルの『状態』はどこまで保証するか

追跡状態	この構成での読み方
NEW	まだ双方向の通信として確立していない新規フローに属するパケット。TCP SYNが代表例。NEWという表示だけでアプリセッション開始や認証成功を意味しない。
ESTABLISHED	追跡器が往復の通信に属すると認識したパケット。戻りSYN/ACKをここで扱う実装がある。暗号化通信の内容やWeb応答コードは確認していない。
RELATED	既存通信に関連すると追跡器が判断した別フローやICMPエラーなど。必要なICMPエラーを通す設計はPMTUDにも関わる。何をRELATEDにするかは実装・ヘルパ設定次第。
INVALID	追跡器が既存の正しい状態へ対応付けられないパケット。破棄・記録して調査するが、非対称経路やタイムアウトのような正常系の設計ミスでも起こり得る。

TCP接続が閉じたり、無通信のまま状態の期限が切れたりすると、同じ五つ組の後続パケットを既存フローとして扱えない場合があります。UDPにはTCPの三者間ハンドシェイクがないため、通信を見た方向とタイマーで疑似的に追跡します。状態の期限は装置設定に依存し、長すぎれば表を占有し、短すぎれば正常通信を切ることがあります。

ステートフルFWでも、許可されたTCP 443のTLS内に不正なHTTP要求があるかまでは通常分かりません。通信の内容を検査するには、TLS終端、WAF、アプリ側の認可とログなど別の位置が必要です。状態追跡は戻り経路の許可を助ける機能であり、業務上の正当性の判断ではありません。

5-1. ステートレスACLなら戻りをどう書くか

状態を記憶しないACLでは、LAN→WANの送信を許す規則だけでは戻りのSYN/ACKを通せません。WAN→LANに、203.0.113.80:443からNAPT後の198.51.100.10:40001へ入る応答を許す条件が別途必要です。しかし多数の動的な外向きポートを静的ルールだけで正確に管理するのは難しく、広すぎる戻り許可は外部からの新規通信も招きます。

方式	戻り通信の判定と残る課題
ステートレスACL	毎パケットをアドレス・ポート・方向などの静的条件で判定する。戻りを通すには適切な逆方向条件が必要。TCP ACKフラグだけを見ても、実際に許可済みの接続へ属するかは保証できない。
ステートフルACL	先に許可した通信の追跡情報に戻りを対応付ける。動的ポートの戻りを個別に列挙しなくてよいが、状態表の容量、期限、非対称経路、再起動後の扱いを設計する。
アプリ層の認可	到達した後に、その利用者がURLやデータへアクセスできるかを判断する。ステートフルACLが戻りを許可しても、アプリ層の認可を省略できない。

ここでのステートレスの戻り条件は概念例です。実装によってはNAPTを伴う場合に戻りの変換対応を作るため、アドレス変換だけは別の状態を持ちます。『フィルタがステートレス』と『装置に状態が一切ない』は同義ではありません。

5-2. 状態表が消えた場合

FWの再起動やフェイルオーバーで追跡状態を引き継がないと、途中のTCPパケットをINVALID又は新規条件に合わないものとして拒否し得ます。NAPT対応も失われれば、198.51.100.10:40001宛ての応答をどの端末へ返すか分かりません。端末側の再接続で新しい状態が作られれば復旧することもあります。

状態テーブルが満杯になったときは、新規通信だけが失敗し、既存通信は一時的に継続する場合があります。表の使用率、フローの発生元、タイムアウト、拒否理由を調べます。攻撃による大量フローと、業務増加による正規フローを、件数だけで断定しないことが大切です。

6. 正常ログを変換前後でつなぐ

次のログは架空の同一時刻の記録です。内部ログのtuple_beforeとtuple_afterは説明用に正規化した表記で、実機が両方を一行に出す保証はありません。すべてUTCとします。

text

10:00:00.100 fw rule=R10 action=allow state=NEW
  before=10.10.1.24:51544->203.0.113.80:443/tcp
  after=198.51.100.10:40001->203.0.113.80:443/tcp
  nat_id=N-91 direction=LAN->WAN
10:00:00.152 fw rule=R02 action=allow state=ESTABLISHED
  before=203.0.113.80:443->198.51.100.10:40001/tcp
  after=203.0.113.80:443->10.10.1.24:51544/tcp
  nat_id=N-91 direction=WAN->LAN
10:01:20.010 fw rule=R20 action=allow state=NEW
  before=203.0.113.66:57000->198.51.100.20:443/tcp
  after=203.0.113.66:57000->10.10.20.10:443/tcp
  nat_id=N-92 direction=WAN->DMZ
10:01:21.004 fw rule=R99 action=deny state=NEW
  before=203.0.113.66:57001->198.51.100.20:22/tcp
  nat_id=none direction=WAN->DMZ

行	確定できること・まだ必要な証拠
R10とN-91	社内端末のSYNが許可され、公開IP:40001へ変換されたこと。外部Webが応答したかは次行、TLSやHTTPの成功は別ログが要る。
R02とN-91	203.0.113.80:443からの戻りが同じNAPT対応で社員端末へ転送されたこと。これは通信経路の成立を示すが、ユーザがページを見た証拠ではない。
R20とN-92	公開IP:443への新規通信がDMZ Webへ送られたこと。DMZ Webのアプリ応答や侵害の有無はWeb・アプリログを別に見る。
R99のSSH拒否	その時刻の外部からのTCP 22新規接続をこのFWが拒否したこと。別の公開IP、IPv6、VPN、他FWを経るSSH経路まで否定はできない。

公開Webの203.0.113.80側が残す接続元198.51.100.10:40001から社員端末を特定するには、時刻、プロトコル、外部宛先、N-91対応と端末記録を合わせます。同じ公開IPを多数の社員が共有するため、公開IPだけでは特定できません。ログ欠落や時計ずれがある場合は対応の確度を明記します。

7. 異常・攻撃の成立条件と対策

異常・攻撃	成立条件、効く対策、残る確認
広い許可ルールが先頭にある	WAN→DMZ anyをR20より上へ追加し、先頭一致で適用されると、SSHなど意図しないポートも通る。変更差分、ヒットカウンタ、外部からの22番拒否試験で検証する。
DNAT先を誤って管理ホストへ向ける	公開IP:443の転送先が10.10.20.10ではなく管理系ホストへ変わると、許可ACLの対象によっては内部サービスを公開する。DNAT値とACLの変換後宛先、実際の接続先を照合する。
NAPT表の逼迫	大量の短時間通信又は攻撃で変換可能なポート・状態表が不足すると、新規通信が失敗する。送信元ごとの上限、不要フローの短い期限、容量監視と増強を組み合わせる。
非対称経路	応答が別FWを通り、元FWの状態・変換に戻らない。ルーティング、冗長構成、状態同期を確認する。片方向の許可ログだけで到達成功としない。
IPv6での迂回	IPv4のNAT・ACLだけを設定し、端末やDMZが別のIPv6経路を使える。IPv6の実際のアドレス、経路、同等のFWルールを確認する。IPv4 NAPTの有無はIPv6の防御にならない。
状態追跡の誤信頼	R02のESTABLISHED許可を『アプリ通信は安全』と解釈すると、許可されたTLS内の攻撃を見逃す。アプリの認可・入力検証と公開側ログを別に整える。

広いACLでSSHが公開されるまで

1. 広い許可を追加：証跡設定差分と承認記録／防御・対処変更前レビューと最小範囲
2. 上位ルールが一致：証跡 rule IDとヒット数／防御・対処順序・重複を検証
3. SSHへ接続可能：証跡 FW通過とSSH受付ログ／防御・対処外部22番の拒否試験
4. 認証を試行：証跡 SSH認証ログ／防御・対処管理認証と試行監視

攻撃者に管理認証情報がなくても、到達可能な面が増える。ログと侵害は区別する。

図の『SSHへ接続可能』はネットワーク到達を意味し、管理者としてログインできたことではありません。SSH認証が破られたかはサーバ側の認証ログが必要です。攻撃者が外部から到達できること、広い許可が実際にヒットすること、公開先でSSHが待ち受けることが成立条件です。

7-1. NATは境界の隠蔽と許可の代わりではない

内部IPが公開IPへ変わると外部から直接は内部IPを見えにくくできますが、DNATやポート転送、既存マッピングとフィルタ条件によって外部から通信できる場合があります。NATのマッピング方式と、どの外部送信元を受け入れるかというフィルタ方式は別です。安全性をNATだけに委ねず、ACLで明示的に制御します。

外向き通信を許可した端末に対する戻り通信は状態追跡で許可されますが、その事実だけで外部から任意の新規接続が許されるわけではありません。逆に、設定ミスで静的マッピングと広いWAN許可が重なれば、管理用ポートも公開され得ます。『NATあり／なし』ではなく、変換表とACLの組合せを確認します。

7-2. 同じ公開アドレスへ社内から接続する場合

社員端末がDMZ Webの公開名を引いて198.51.100.20:443へ接続すると、通信はFWの外へ出ずに内部から公開IPへ戻る経路を通る場合があります。このヘアピン通信を許すかはFWのNAT・ルーティング・ACL設定次第です。外部からのR20許可があるだけで、社内からも同じ公開名でつながるとは限りません。

ヘアピンが必要なら、LANから公開IPへのDNATと、応答が必ず同じFWを経るための送信元変換・経路を設計します。一方で、社内DNSがDMZの私設IPを返す設計なら、社内通信は別のACL経路になります。社内からつながらない障害では、名前解決結果、FWの入出力インターフェース、変換前後、戻り経路を順に確認します。

7-3. ICMP・UDP・断片化の例外

ICMPエラーをすべて拒否すると、必要な到達不能通知やPath MTU Discoveryに影響する場合があります。RELATEDとして通すICMPは、対応する元の通信と関連を検証します。外部からの任意のICMPを通す設定と同一視しません。

UDPのNAPTではTCPの終了フラグがないため、タイムアウトと送信方向で対応を維持します。長時間応答がないとマッピングが消え、遅れて来た応答は元端末へ戻せません。IP断片化では全断片にポート番号があるわけではなく、装置の再構成・追跡方式とポリシーを確認します。

8. 変更、障害、復旧をどう進めるか

FWルール変更ではまず通信要件を申請者と確認します。送信元ネットワーク、宛先サービス、プロトコル、ポート、方向、期間、業務責任者を記録し、既存ルールへの影響を評価します。『一時的にanyを許す』ときも期限と自動的な棚卸しを定め、変更前の設定と状態表の影響を把握します。

既存の許可ルールを狭めても、変更前に作られた状態が期限まで残り、通信がしばらく続く実装があります。緊急遮断ではACL更新のヒット確認に加え、該当する状態・NAT対応の削除、別経路の遮断を検討します。状態を一括削除すると正常な業務通信も切れるため、対象の五つ組を特定して影響を見積もります。

変更の承認と実装を分ける場合、承認者には『何をどこまで公開するか』を示します。実装者はルールの前後関係、NATの評価点、IPv4とIPv6の両方、冗長装置への反映、ログ採取を確認します。変更後は許可される通信だけでなく、禁止したい通信が確実に拒否されることまで試験します。

誤公開を検知した後の対処

1. 公開を確認：対応 ruleと接続履歴を保全／確認する証跡設定差分・FWログ
2. 経路を閉じる：対応広い許可を撤回／確認する証跡 22番の外部拒否試験
3. 侵害を調査：対応 SSH認証と操作を調べる／確認する証跡認証・端末・操作ログ
4. 許可を再設計：対応管理網だけを許可／確認する証跡 ACL・NAT・経路表
5. 再開を判断：対応正規接続と拒否を試す／確認する証跡試験・承認記録

広いWAN許可でDMZのSSHが到達可能になった事例。到達とログインを分けて確認する。

単に広いACLを削除しても、公開期間中に取得された管理資格情報や不正なアカウントは残り得ます。SSHの成功・失敗ログ、sudo等の操作、鍵登録、横展開を調べます。侵害が疑われれば資格情報の交換や端末復旧を行い、正規の管理接続が管理網から可能であることを確認します。

正常試験：社員端末のTCP 443がR10とNAPTを経て外部Webへ届き、戻りがN-91で元端末へ戻る。公開WebはR20とDNATでDMZへ届く。
拒否試験：WANから公開IPのTCP 22、WANからLANへの新規接続、許可外のUDP・IPv6経路が意図どおり拒否される。
変更試験：ルールの先頭一致順、NAT前後の照合値、影響する既存状態、冗長FWの切替えと状態同期を確認する。
復旧試験：状態表消失後に新しい接続が再確立し、ログで端末IPと外向きIP:ポートを追跡できる。

9. 科目B（午後）の記述演習

演習1：戻り通信の許可理由

条件：R10で10.10.1.24:51544→203.0.113.80:443を許可し、N-91を作った。203.0.113.80:443→198.51.100.10:40001が戻る。問い：WANからの新規許可ルールがなくても戻せる理由を述べよ。

解答：FWがN-91と追跡状態で許可済みフローの応答を識別し、宛先を10.10.1.24:51544へ逆変換できる。誤答『WANからの全通信を許可している』はR02が既存フローへの一致を条件にする点を見落としている。

演習2：公開WebのACL宛先

条件：このFWではDNAT後に転送フィルタを評価し、198.51.100.20:443を10.10.20.10:443へ変える。問い：R20の宛先と、その理由を述べよ。

解答：R20は10.10.20.10:443を照合する。フィルタに届く時点で宛先がDMZの値だからである。誤答『必ず198.51.100.20を書く』は製品・評価点を確認せず、変換前後を混同している。

演習3：NAPTログからの端末特定

条件：外部Webに198.51.100.10:40001からのアクセスが記録された。問い：社内の利用端末をどう特定するか。

解答：時刻、プロトコル、外部宛先と公開IP:40001に対応するN-91を探し、10.10.1.24:51544と端末ログを照合する。誤答『198.51.100.10は一人の端末』はNAPTで複数端末が公開IPを共有する点に反する。

演習4：ACLの広い許可

条件：R20より前にWAN→DMZのTCP any許可を追加し、外部からSSHのTCP接続が成立した。問い：原因と、侵害の有無を調べる追加証拠を述べよ。

解答：上位の広い許可が先に一致した可能性がある。rule IDと設定差分に加え、DMZサーバのSSH認証成功・失敗、操作ログを調べる。誤答『接続成立だけで管理者権限が奪われた』は到達と認証を混同する。

演習5：FW切替え後の既存通信

条件：冗長FWへの切替え後、既存のHTTPSだけが切れ、新しい接続は成功する。問い：まず調べる状態と対処を述べよ。

解答：切替え前の追跡状態とNAPT対応が新FWへ同期されたか調べる。既存フローが復元不能なら端末の再接続を促し、必要な継続要件があれば状態同期を設計する。誤答『外部Webが必ず故障した』は新規接続成功の条件に合わない。

演習6：IPv4のFWだけ設定

条件：IPv4のWAN→DMZはR20のTCP 443だけだが、DMZ WebにIPv6の公開アドレスがある。問い：追加で何を確認するか。

解答：IPv6のアドレス・経路・WAN→DMZルールを確認し、意図しないポートが拒否されるか外部から試す。誤答『IPv4でNAPTしているからIPv6も保護される』は両経路を同じものと扱っている。

10. 一次資料と確認先

FWの構成・ポリシー、NAT・NAPT、状態追跡に関する一次資料です。具体的なルール評価順、状態名、ログの前後値は導入FWの仕様と実機で検証します。

NIST SP 800-41 Rev. 1：FWとポリシーの設計・運用

RFC 3022：従来型NATとNAPTの変換

RFC 4787：UDP NATのマッピングとフィルタの区別

RFC 5382：TCP NATの動作要件

nftables：状態追跡メタデータと状態名

nftables：NATの処理順とバインディング

FW・ステートフルインスペクション・ACL・NAT／NAPT