続報で残したのは、「社内→公開グローバル IP 宛が、境界で通常どおりの NAT 変換を経由していない可能性が高い」というところまでだった。設定者と経緯は、まだ言えない範囲として残してある。

社外網からは、同じ URL https://corp.example.jp が変わらず開ける。DMZ サーバも応答している。困っているのは、社内 LAN の端末からだけだ。

ここから先は、「直しに行く」段階ではない。先に決めるのは、どこを最小範囲で動かすか、戻らなかったときにどこで止めるか、社内から戻ったあとに何をそろえれば「戻った」と言えるかだ。

隣の席で、瀬戸が前のめりになる。

「原因らしい場所は見えましたよね。早く境界を直して、社内からも開けるようにしましょう」

氷室がモニタから目を上げる。

「『原因らしい場所が見えた』ことと、『戻していい場所が決まった』ことは別物よ。あなた、いま境界のどこを、どう書き換える気だったの？」

瀬戸は固まった。

「えっと……境界に、社内から 203.0.113.10 宛の経路を通せばいい、っていう……」

「『通せばいい』は手順じゃない。最小で済む案と、もう少し広い案を並べてから、どっちが先に戻せて、どっちが先に戻せなくなるかを比べる。直す前は、まずそこ」

氷室は手元のキーボードを瀬戸ではなく、あなたのほうへ滑らせた。

直す場所を、どこまで狭められるか

続報の段階で、社内/社外の対比、DNS 解決値、境界の変換表、公開サーバ側の source IP、ACL/uRPF は揃っている。社内 DNS は社外と同じグローバル IP を返し、サーバ自体も生きている。境界の show ip nat translations だけが、社内→203.0.113.10 宛のエントリを出していない。

「ここで瀬戸が言いたかった案」と、「別の戻し方」と、「やってはいけない案」を、3つ並べる。

瀬戸が画面を覗き込んで言う。

「3つ目は、論外ですよね。社外網側からも今は開けてるのに、それを巻き込むのはまずい」

「『まずい』で終わらせない」氷室が即座に切り返す。「観測と一致するのは、社内→公開グローバル IP 宛だけ変換されていない、という範囲。残り 2 つも社外網側は動いてる。なら、変えていい範囲は『社内→公開グローバル IP 宛だけ』。それを超える変更を選ぶ理由は、いま観測のどこにもない」

瀬戸が頷く。

「つまり、社外網側に追加で何かやる必要が出ていないうちは、境界の static NAT 1 行か、内部 DNS かの 2 択ってことですか」

「ようやくまともな比べ方になったわね」

2 案のうち、社内端末すべての DNS キャッシュを揺らす内部 DNS 案は、戻し方の単位も大きい。境界 1 台の static NAT 1 行に hairpin 用オプションを足す案なら、戻すのもオプションを 1 つ外すだけだ。

今回選ぶのは、境界の static NAT 側。内部 DNS の split を「採用しない」のではなく、「今回の最小修正としては選ばない」という整理になる。社内向けに DMZ private IP を返す設計自体は、運用ポリシーとして別途検討する材料として残す。

戻らなかったとき、どこで止めるか

直す案より先に固めるのは、「直して戻らなかったら、どこで判断を打ち切るか」のほうだ。

境界に hairpin 用の 1 行（公開グローバル IP 203.0.113.10 宛のホスト経路）を足す変更は、その 1 行を no で外せば元に戻る。だから「戻せる」だけでは不十分で、いつ戻すかの線を引いておく。

• 戻し条件: 変更後 3 分以内に、社内端末からの curl 成功と、社員からの利用者確認のいずれかが戻らない。あるいは、社外網側からのアクセスや、境界配下の他公開サービスに追加影響が出る。
• 戻し操作: 追加した ip route 203.0.113.10 ... を no で外し、running-config を変更前の差分へ戻して、上位へエスカレーションする。
• 判断時間: 3 分。

瀬戸が手帳を開きながら聞く。

「3 分って、ずいぶん短いですね。少なくとも 30 分くらい様子見たほうが……」

氷室は短く首を振る。

「社外網側からは今も開けてる。あなたの 30 分の様子見の間に、社外網側でもう 1 つ別の症状が出たら、それは新しい変更が混入したのか、もとからあった別件なのかの切り分けができなくなる。戻すなら『迷いの幅』を作らない時間で戻す」

瀬戸が、自分の言葉で置き直す。

「つまり、3 分以内に社内 curl か利用者確認のどちらかが戻ってこなかったら、ほかを観察する前に、まず元の設定に戻して、いったん追加変更を止める。そのうえで、社外網側に変化が出ていないかを確認する、って読み方でいいですか」

「やっと『手順』の形になったじゃない」

承認は、運用リーダーに取る。対象は境界 1 台、対象行は対象 static NAT に対応するホスト経路の追加 1 行のみ、戻し条件はこの 3 分、戻し操作は no ip route 203.0.113.10 ... の 1 行。ここまでが揃って、はじめて変更窓に入る。

戻り道を、1 行で作る

境界ルータ BORDER の現状を、変更前にもう一度見ておく。

interface Ethernet0/0
 description outside
 ip address 203.0.113.1 255.255.255.0
 ip nat outside
!
interface Ethernet0/1
 description inside
 ip address 10.10.0.1 255.255.255.0
 ip nat inside
!
ip nat inside source static 192.168.100.10 203.0.113.10
ip nat inside source list INSIDE-OUT interface Ethernet0/0 overload

inside と outside の向きは付いている。社内 LAN→外部宛の overload も入っている。192.168.100.10 を 203.0.113.10 に出す static NAT も、もとから 1 行入っている。

足りないのは、社内 LAN から自分側の公開グローバル IP 203.0.113.10 宛の通信を、境界の中で内側へ折り返す経路だ。境界の routing table には 203.0.113.0/24 が outside 直結として入っているだけで、203.0.113.10 だけを inside 側へ向ける線は引かれていない。そこに、203.0.113.10/32 のホスト経路を DMZ 側 next-hop で 1 行足す。static NAT は今のままで残し、足すのは「ホスト経路 1 行」だけになる。

実施するコマンドは、これだけだ。

configure terminal
ip route 203.0.113.10 255.255.255.255 Ethernet0/2 192.168.100.10
end

変更後の running-config の差分は、ホスト経路 1 行だけだ。

ip nat inside source static 192.168.100.10 203.0.113.10
ip nat inside source list INSIDE-OUT interface Ethernet0/0 overload
!
ip route 0.0.0.0 0.0.0.0 203.0.113.2
ip route 203.0.113.10 255.255.255.255 Ethernet0/2 192.168.100.10

それ以外の行は、変更前のままになっている。ip nat inside / ip nat outside の向きも、static NAT 本体も、overload で動いている社内 LAN→外部宛の PAT 設定にも手を入れていない。社外網側からアクセスしている人にとって、何かが変わったように見える経路は、いまの変更には含まれていない。

瀬戸が、差分の少なさを見て呟く。

「1 行だけって、本当に 1 行だけなんですね……。もっといろいろ書き換えるかと思ってました」

氷室が短く言う。

「観測で『社内→公開グローバル IP 宛の戻り経路だけが通常と違う』と分かっているのに、それ以外まで触る理由はないでしょう。戻し方を 1 行に抑えたいから、変更も 1 行に抑える。当然」

「戻った」と言うために、何をそろえるか

入れて、社内 curl が 200 を返した。瀬戸が小さく拍手しようとする。

「戻りましたね。じゃあ、社員さんに『直りました』って連絡を……」

「待ちなさい」氷室が片手で制した。「社内端末 1 台の curl が 200 を返したから直った、って言えると思う?」

瀬戸が止まる。

「えっと、戻ったには戻ったので……」

「あなたが今直したのは、境界の static NAT 1 行よ。それで戻ったかを確かめるには、最低でも 4 つ別々のところを見る。1 つでも欠けたら、それは『戻ったように見えた』だけ」

確認していくのは、つぎの順番だ。

1 つ目は、社内端末からの疎通そのもの。

INTERNAL-PC$ curl -sI --max-time 5 https://corp.example.jp | head -n 1
HTTP/1.1 200 OK

2 つ目は、社外網側が変わらず開けるかどうか。今回いじったのは社内→公開グローバル IP 宛の戻り道で、社外網側にはもとから影響しないはずだが、「はず」では足りない。テザリングなど社外網経由でも、同じ URL がそのまま開けることを確認する。

MOBILE$ curl -sI https://corp.example.jp | head -n 1
HTTP/1.1 200 OK

3 つ目は、境界の変換表に、社内→公開グローバル IP 宛のエントリが現れているかどうか。続報の段階で「ここに出ていない」ことを根拠にしてきた場所なので、ここが復旧後にどう変わるかを必ず見る。

BORDER#show ip nat translations | include 203.0.113.10
Pro  Inside global         Inside local          Outside local         Outside global
tcp  203.0.113.10:443      192.168.100.10:443    10.10.0.20:51234      203.0.113.10:443

Outside local 側に、社内端末 10.10.0.20 が現れている。境界の中では、社内からの問い合わせが outside 側のセッションとして扱い直されている。

4 つ目は、サーバ側に届く source IP。続報で、ここに 10.10.0.20 がそのまま残っていたのが反証の中心だった。復旧後は、社内アクセス分の source IP が境界の outside global 側に揃っているはずだ。

203.0.113.10 - - [Mon:09:42:18 +0900] "GET / HTTP/1.1" 200 2401
203.0.113.10 - - [Mon:09:43:02 +0900] "GET / HTTP/1.1" 200 2401

10.10.0.20 のような社内 LAN の private IP は、もう残っていない。

ここまで来て、ようやく社員側に「業務復旧の確認」を取る。複数フロアの社員に、社内 PC から https://corp.example.jp を開けるかをチャットで確認したところ、「開けます」と返ってきた。同じ時間帯に追加の申告も入っていない。

瀬戸が、確認結果を見ながらつぶやく。

「社内 curl だけだったら、たとえば社内 LAN の 1 セグメントだけ戻ってきた状態でも、200 が返って終わった気になっちゃうんですね。境界の変換表とサーバ側ログ、両方戻ってきて、利用者からも『開ける』が返ってきて、社外網側も継続して開けてる――ここまでで、はじめて『戻った』なんですか」

「やっとまともな確認の組み立てになったわね」氷室が短く返す。「技術側で 200 を 1 つ取って終わりにしない理由は、そこにある」

社員側への完了連絡は、長い文章にはしない。「社内 PC から自社サイトを通常通り開ける状態に戻った。社外網経由でアクセスしていた人も、通常手段に戻してよい。追加で気になる動きがあれば連絡してほしい」――それだけで足りる。詳細な観測順や変更内容は、社員側の判断には要らない。

報告書に残すのは、直した事実だけではない

ここまで来て、ようやく報告書に向き合う。

ただし、復旧した事実だけを書いて閉じてしまうと、次に同じ違和感を踏んだ人が、社内/社外の対比 → DNS 解決値 → 境界の NAT 経由有無 → サーバ側 source IP、という今回と同じ観測順を一からやり直すことになる。それでは、今回の障害対応で消えた時間が、組織側に残らない。

氷室が、あなたの隣に椅子を引きながら言う。

「報告書って何を書くものか、瀬戸の言葉で言ってみなさい」

瀬戸が少し詰まってから答える。

「えっと……直った事実と、原因と、修正内容と……再発防止案、ですかね」

「『再発防止案』を、いま書ける?」

「えっと……境界の hairpin 設定が、いつ、誰の判断で消えたか分かってないので、書けないです」

「そう。それを『分かったふり』で書いて閉じると、次に同じことが起きる。報告書は、直った事実を書く場所であると同時に、『まだ言えない範囲』を、後から触る人のために残しておく場所でもある」

報告書に残すのは、つぎの 6 つに分ける。順番は、共有先の判断に効く順にしてある。

• 復旧した事実: 社内 LAN の INTERNAL-PC から https://corp.example.jp を開けることを確認。複数フロアの社員からも、社内 PC で開けるとチャットで確認できた。同時間帯に追加の申告なし。
• 原因として言える範囲: 境界ルータで、社内→公開グローバル IP 宛に対する戻り経路の NAT が無効だった。社内 source IP のまま DMZ サーバへ届き、サーバ側の戻り経路で default GW 経由に乗って drop されていた範囲までは、複数観測の方向が一致している。
• まだ言えない範囲: 当該設定がいつ、誰の判断で現状（未設定）になっていたか。初期構築時から外れていたのか、過去のいつかの変更で外れたのかも、変更履歴を別途確認中。
• 実施した修正: 境界に ip route 203.0.113.10 255.255.255.255 Ethernet0/2 192.168.100.10 のホスト経路 1 行を追加し、社内→公開グローバル IP 宛が境界で内側へ折り返されて static NAT を経由するようにした。static NAT 本体は触っていない。
• 検証結果: 境界の show ip nat translations で社内→公開グローバル IP のエントリ出現、社内 curl 成功、社外網経由の curl 継続成功、公開サーバ側 httpd ログの source IP が outside global 側に揃ったこと、社員からの利用者確認で開けることを確認。
• 記録へ戻す事項: 公開サービスの内部公開方式（社内向けに DMZ private IP を返す内部 DNS の検討）を、運用ポリシーとして別票で起票候補にする。境界の static NAT に対応するホスト経路の構成 drift 監視（該当 ip route の有無を含む差分検知）を、定期点検項目に追加するかを別票で検討。

瀬戸が、6 つを順に読み直してから言う。

「今回は最小で境界 1 行だけ動かしましたけど、内部 DNS の split を採用するかは、別の場で考えるんですね。そこを『今回の最小修正で潰した話』として閉じないで、別票として残すと」

氷室が短く頷く。

「あなたがいま選ばなかった案を、『選ばなかった』とだけ書いて閉じると、次に同じ判断をする人は、ゼロから比べ直すことになる。比べたうえで今回はこちらを選ばなかった、と残しておけば、次は同じ比較を 2 回しなくていい」

最後に、報告書の宛先は、研修担当シニアの氷室と、運用リーダーに向ける。社員側にはすでに復旧連絡が返っており、社員側に渡す文書はこの報告書ではない。社員側に必要だった情報と、運用側に必要な情報を、同じ紙にまとめないのが、復旧後の片付け方になる。

1 行の変更を残すために、何を一緒に置いたか

今回境界に足したのは、公開グローバル IP 203.0.113.10/32 のホスト経路 1 行だけだ。本数で言えば、ほとんど何も足していない。

それでも、変更前に並べて固定したのは、最小範囲の選び方、戻し条件と戻し操作、復旧の言える条件、報告書に残す 6 つの分け方だった。直すこと自体より、これらをそろえることのほうに、ずっと多くの行を使っている。

次に、社外網からは開けるのに社内 LAN からだけ届かない、という申告がまた入ったとき、その人は今回の報告書を読めばいい。社内/社外の対比から始まり、DNS 解決値、境界の変換表、サーバ側 source IP、そして hairpin の有無まで、観測の順番がそのまま残っている。「まだ言えない範囲」も隠さず残っているから、次の人は「今回の修正で何が直り、何が直っていないのか」から読み始められる。

氷室が、画面の報告書を眺めながら言う。

「変更 1 行を入れる前に、戻し方と、戻ったと言える条件と、まだ言えない範囲まで先に置いたわよね。それが残っていれば、次に同じ症状を踏んだ人は、ここを足場にできる」

瀬戸が小さく息を吐く。

「直したコマンド 1 行よりも、その周りに置いた行のほうが、ずっと長く残るんですね」

「気づくのが遅いのよ」と氷室は言いつつ、画面から目を離さない。「次に社外網からは開けるのに社内から開けない、っていう申告が入ったとき、いきなり境界を触りに行く人と、社内/社外の対比から始める人とで、最初の 30 分が変わる。今回あなたが残した順番は、その『最初の 30 分』を、次の人に渡すための材料よ」

社内 LAN だけ届かない、という症状そのものは、構成によってはまた似た形で別の場所から出てくる。境界での戻り経路の話なのか、内部 DNS で社内向けに別 IP を返す話なのか、ACL や uRPF の話なのかは、その都度観測で分ける必要がある。今回の報告書は、その「分け方の地図」として残る。

氷室は、瀬戸ではなくあなたのほうを見て、短く言った。

「やっとまともな報告書になったじゃない」