[🛠] IT Operations #1: 会社のルーターの「インターネット接続なし」を解決した方法（feat. Codex）

✨ GPT-5.6 Solの要約

スマートフォンを2階のルーターに、Macのブラウザを会社のルーターにつないでCodexが実機を直接診断できるようにし、その過程を見ながらネットワークをリアルタイムで学んで障害まで復旧した記録。

今日、会社の2階のWi-Fiがおかしかった。電波は非常によく入るのに、インターネットにはつながらない。ルーターは起動していてスマートフォンも接続できているが、画面にはずっとインターネットに接続されていませんと表示されていた。

目の前のルーターには電源が入り、LANランプも動いていた。外見だけでは、どこで止まっているのか分からなかった。

以前なら、ルーターの電源を何度か入れ直し、LANケーブルを間違った場所に挿していないか確認し、それでも直らなければ検索を始めていただろう。だが二日前、AIを積極的に活用できれば、できることは無限に広がるを書きながら、新しい作業方法を一つ覚えた。

実際の機器と画面をAIにつないでやればいい。

今回はその方法をすぐに使った。スマートフォンをUSBでMacにつなぎ、ADBを開いた。スマートフォンは問題が起きた2階のWi-Fiに接続した。スマートフォンのChromeでは2階ルーターの管理画面を開いてログインし、MacのChromeでは会社ルーターの管理画面を開いてログインした。そしてCodexに指示した。

重要なのは、私がルーターの設定をすべて自分で解明したことではない。Codexが実際に作業できるよう、物理機器、コマンド実行環境、ログイン済みの管理画面を先にセットアップしたことだ。

まず現在の状況を把握して。むやみに変えると問題が起きるかもしれないから、できるだけ先にコマンドで解決を試みて。

これでCodexは説明だけするチャットボットではなくなった。スマートフォンのネットワーク状態をコマンドで読み、私がログインしておいた二つの管理画面をComputer Useで行き来しながら、実際の設定を確認して変更できるようになった。

スマートフォンとブラウザをつなぎ、二つのネットワークを同時に見せる

最初は、なぜ192.168.0.1が開かないのかさえ分からなかった。調べてみると、二つのルーターは異なる役割を持っていた。

会社ルーター 192.168.0.1
  └─ 2階ipTIME WAN 192.168.0.86
       └─ 2階Wi-Fi / LAN 192.168.1.x
            └─ 2階ルーター管理画面 192.168.1.1

Macは社内ネットワークにつながっているため、会社ルーターの192.168.0.1を開けた。一方、2階Wi-Fiに接続したスマートフォンは192.168.1.xのアドレスを受け取り、192.168.1.1をgatewayとして使っていた。そこでMacのブラウザには会社ルーターを、スマートフォンのブラウザには2階ルーターを開いておいた。

画面を見せただけではない。ADBがつながっているため、Codexはスマートフォンが受け取ったIPとrouteを読み、2階Wi-Fiのinterfaceを指定して通信を直接検査した。スマートフォンはWi-Fiが切れてもモバイルデータでインターネット接続に成功できるので、単にpingを実行すると結果を見誤る可能性があった。

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

結果はこうだった。

• スマートフォンから2階ルーターの192.168.1.1までは応答した。
• 会社ルーターの192.168.0.1から先は応答しなかった。
• 外部IPの1.1.1.1も応答しなかった。
• HTTPS検査は000で終わった。

私はこの過程を隣でそのまま見ていた。Wi-Fiの電波が入るということは、スマートフォンと2階ルーターの間がつながったという意味にすぎなかった。問題はその先、2階ルーターのWANが社内ネットワークへ出る区間にあった。

先にネットワークの本を開き、LAN、WAN、gateway、二重NATを順に勉強したわけではない。実際の障害をCodexが一つずつ切り分けて検査する様子を見ながら、192.168.0.1と192.168.1.1がなぜ両方存在するのかをすぐ理解できた。

DHCP leaseが正常でも通信は遮断される

同じ日、開発NASとデータNASのIPも変わっていた。会社ルーターのDHCP client一覧から現在のアドレスとMACアドレスを探し、二台のNASが次回も同じアドレスを受け取るよう予約した。先にNASへ移した年休自動化へ入るHTTP・HTTPSのport forwardingも、新しいアドレスを指すように合わせた。

その過程で、DHCPが何かも必要になった瞬間に学んだ。

• 通常のDHCP割り当ては、空いているIPを機器に貸し出す。
• DHCP予約は、特定のMACアドレスが接続したときに同じIPを与える。
• 機器自体に固定IPを設定することと、ルーターでDHCP予約を設定することは異なる。

しかし、2階ルーターの問題はDHCP予約だけでは説明できなかった。ipTIMEの管理画面には外部IPが192.168.0.86と表示され、状態もインターネットに接続だった。会社ルーターにも、同じIPを現在のipTIMEへleaseしている記録があった。

途中でCodexはDHCP一覧の現在のpageだけを見て、.86がないと誤って判断した。clientが90台を超え、一覧が複数pageに分かれていたが、私は別のpageですでに該当する行を見ていた。

あるけど？

MACアドレスと.86のlease行をもう一度見せると、調査の方向が変わった。IPを受け取れていない問題ではなく、IPを受け取った後の通信を遮断する設定を探す必要があった。

WAN接続を切断して再接続しても結果は同じだった。access controlは有効だったが、blacklistは空だった。そこでIP&MACバインディング画面から原因が見つかった。.86は現在のipTIME WAN MACではなく、以前使っていたdesktopのMACに結び付けられていた。

DHCP server: 現在のipTIMEに192.168.0.86をlease
IP&MAC binding: 192.168.0.86は以前のPCのMACだと記録

DHCPは現在の機器にアドレスを与えていたが、security設定はそのアドレスの所有者を別の機器だと見ていた。そのためipTIMEは管理画面上ではIPを受け取ったように見えながら、会社ルーターとは通信できなかった。

IPを受け取ったこととそのIPで通信できることは同じではなかった。これも障害を追ううちに自然と理解できた。

古いバインディング一件だけを削除し、実際のWi-Fiで再検証する

ルーターのsecurity機能全体は無効にしなかった。問題となった.86の古いIP–MACバインディング一件だけを削除し、ipTIMEのWAN接続を再ネゴシエーションした。

今度はすぐに結果が変わった。

192.168.0.1  ping成功
1.1.1.1      ping成功
HTTPS        204
Android Wi-Fi VALIDATED

復旧後は、現在のipTIME WAN MACが常に.86を受け取るようDHCPアドレス予約を追加した。DHCP予約は現在の機器へ同じアドレスを継続して与え、IP–MACバインディングはそのアドレスを使える機器を強制する。今回の障害は、二つの記録が別々の機器を指していたために起きた。

インターネットは復旧したが、2階のipTIMEが社内ネットワークの下に別の192.168.1.xネットワークを作る二重NAT構造はそのままだ。AP・hub modeへ変えるには、DHCPと管理IPだけでなく、実際のLANケーブルがWANとLANのどちらに挿さっているかも変えなければならない。遠隔から不用意に触れば、管理画面と2階の機器を一度に失う可能性があるため、今日は確認できたインターネット障害の原因だけを直した。

ネットワークをすべて学んでから直したのではなく、直す過程を見て学んだ

今日私がしたことの核心は、ネットワーク知識を先にすべて勉強してルーターを直したことではない。

問題が起きると、7月22日に見つけた作業方法をすぐに取り出した。自分にしかできない物理的な接続とログインを先に行った。スマートフォンを2階Wi-Fiにつなぎ、USBでMacに接続した。二つのルーター管理画面をそれぞれ開いた。変更範囲を定め、Codexが見落としたDHCPの行が見えたら改めて指摘した。

そこからCodexが動けるようになった。コマンドでどの区間まで通信できるか確認し、Computer Useで二つの管理画面の設定を読み、考えられる原因を一つずつ消し、必要な一件だけを修正して同じスマートフォンで再検証した。

さまざまなネットワーク知識を別に勉強してから実戦に入ったわけではない。その場で必要な概念が、実際の画面とコマンド結果に結び付いて入ってきた。DHCP、MACアドレス、gateway、LANとWAN、IP–MACバインディング、二重NATが暗記する用語ではなく、目の前の障害がなぜ起きたのかを説明する道具になった。

AIも最初から常に正しいわけではなかった。.86を見落としたように、誤った判断もした。しかし、私が実際の画面を見て不自然な点をもう一度示すと、Codexはすぐ次の検査へ進んだ。私はすべてのコマンドや設定menuを先に知る必要はなかったが、結果がおかしいかを見て目標を定め直す役割は続けなければならなかった。

二日前には、AIにブラウザとスマートフォンをつなげれば、自分で直接扱える領域が広がると初めて気付いた。今日はその気付きを、実際の会社の障害に積極的に使った。

知らない分野を何週間か勉強して、いつか実戦で使う方法だけがあるわけではなかった。実際の問題をAIと一緒に解決しながら、その瞬間に必要な分だけ学び、すぐ結果まで出す方法もあった。