いつも通りやったのに1週間通らない。。。犯人はNATでした【情シス備忘録】

※構成は特定を避けるため、かなりぼかして書いています。

依頼はいつものやつ

うちの会社には、普段の社内ネットワークとは別に、FWで制限をかけた現場用のネットワークがあります。

今回の依頼は「別拠点にある管理用のPCから、現場用ネットワークのAPの管理画面に入れるようにしておいてほしい」というもの。

普段なら、FWの「制限解除用のグループ」にそのPCのIPアドレスを登録するだけ。自分の事務用PCでも何度もやってるし、5分で終わる作業です。…のはずでした。

結果、1週間ちょっとかかりました。

図にするとこんな感じ。

自分のPCは現場用FWと同じ拠点にいるけど、今回のPCは別拠点から、しかも途中でIPを変換されてやってくる、というのがミソでした。

通らない。。。

まずは自拠点からリモートで設定。

いつも通りグループに登録して、pingを打つ。

届かない。

（あれ、なんでだ？設定間違えたかな？）

tracertを打ってみると、拠点間を抜けて現場用ネットワークの手前あたりで、どうあがいても消える。

じゃあFWで落ちてるんだろうとログを見に行くと、何も残ってない。

（ん〜別拠点だからなのか？それともどっかに自分のしらない設定が入ってるのか？）

試しに自分のPCからアクセスしたら普通につながる。

そうだよね、そういう設定をしたんだもの。

同じようにリモート側の設定を確認して、FWにIPをうって制限解除してるグループに放り込む。

けど繋がらない。

（なんでや！！！）

自分の環境だと、FWの画面からは通った通信のログしかうまく見られなかったんですよね。

拒否された通信を見ようとCLIでの確認方法も調べて試したんですが、これもうまくいかず。

AIにも壁打ちしてみたものの、返ってくるのは「暗黙のルールで落ちている可能性」「戻りの経路がない可能性」といった答え。

どれもそれっぽいけど、確かめようにもログが見えないので決め手がない。

設定を見直しては、pingを打って、届かない。

これを何日か繰り返しました。途中定例会でうまく繋がらないって上司に伝えたけど、普通に設定すれば繋がると思うよ〜とのこと。

（繋がんないから相談してるんだけどな〜。。。）

正直、このへんで一回心が折れかけました笑

現地に行ったら、Wi-Fiだと通る

そんな中、その拠点に行く用事ができたので、直接PCを触りながら確認することに。

普段はIPが変わらないよう有線LANでつないでるんですが、試しにWi-Fiでつないでみたら……通る。

そこへ、たまたま同じ拠点に出張していた上司が登場。

二人で「このIPだけ何か特殊な設定で通らないようになってるのかな？」と話しつつ、有線のまま別のIPに変えて、そのIPも現場用ネットワーク手前のFWで許可してみたら、これも通る。

「じゃあ、もうIP変えちゃいますか〜」

と言いかけたところで、ふと思い出して確認しました。

「そういえばこのPCって、特別扱いの設定にしてましたよね？IP変えたら外れちゃいません？」

「あ〜、それはね、拠点のFWでNATしてるんだよね〜」

……それが原因じゃね？笑

原因：途中の機器から見えていたのは別のIPだった

このPCの通信は、事情があって、その拠点を出る時点でFWによって送信元IPが変換（NAT）されていました。

つまり、その先のFWからは、PC本来のIPではなく変換後のIPに見えていたわけです。PC本来のIPでいくら穴を開けても、そりゃ通らない。

Wi-Fiや別のIPで通ったのは、NATの対象から外れて、元のIPのまま届いたから。

しかもこのNATは別拠点を出るときだけの設定なので、自拠点のPCでは絶対に起きない現象です。

この経路で通信する端末自体ほとんどなく、前例がなかったのも気づけなかった理由でした。

最終的には、変換後のIPを制限解除のグループに追加して解決。

ついでに、もう使われていない古い登録もまとめて整理しました。

今回の学び

「IPを登録すれば通る」というのは、途中の機器から見えるIPがPC自身のIPと同じ、という前提があって初めて成り立つ話でした。同じ拠点の事務用PCではNATが挟まらないから、その前提に気づいてすらいなかった。

それから、拒否された通信のログを見られるようになっておきたい、というのも反省点です。

どこで落ちているかが見えていれば、もっと早く「知らないIPで来てる」と気づけたはず。

あと、机上で詰まったら現地で条件を変えて試すこと、そして「この端末、何か特別扱いしてません？」を経緯を知っている人に早めに聞くこと。

1週間悩んで、最後に効いたのは上司との雑談でした笑

もうひとつ。この1週間、AIとはかなり壁打ちしました。「暗黙のルール」も「戻りの経路」も、一般論としては全然間違ってないんですよね。

でも今回の答えは、「うちの会社のこの拠点のFWに、こういう設定が入っている」という、うちの環境の中にしかない情報でした。そこはAIには絶対にわからない。

結局、調べるべきだったのは設定の中身と、経緯を知っている人の頭の中でした。AIで原因の候補を絞りつつ、環境固有のところは人に聞く。この使い分け、大事だなと思いました。

今後は、どの端末をどういう理由で許可しているのか、運用ルールもちゃんと考えないとなぁと思っています。

おわりに

そういえば前にも似たようなことがありました。Windowsのドライバーがおかしくなって、PCの音がまったく出なくなったとき。

AIに聞いても解決せず、いろいろネットサーフィンしてたらたまたま見つけた個人のブログ記事に救われたんですよね。

誰かが自分の環境で詰まって、なんとか解決して、それを書き残してくれていたおかげです。

拠点をまたいだNATなんて、まったく同じ状況の人はそうそういないかもしれません。

でも、もしどこかで「いつも通り設定したのに通らない」と頭を抱えている情シスの人がいたら、この備忘録がちょっとでもヒントになればうれしいです。