🔗 現象
- Macbook Air 2024（M3）
- macOS Sequoia
- ESET Cyber Security V8.2.800.0
macOS Sequoiaのリリース後、ESETが11月中頃にmacOS Sequoiaに対応したので、手順に沿ってESETをまずアップグレードし、それからmacOSをSequoia 15.1にアップグレードしました（その後Sequoia 15.1.1もリリースされました）。
参考: macOS Sequoia 15.x への対応について | ESETサポート情報 | 個人向け製品 | キヤノン
ESETとmacOSのアップグレード自体はうまくいったようなのですが、その後、ローカルで起動したWebアプリにアクセスできなくなっていることに気づきました。🫠
- devcontainerで動くRailsをVS Codeで起動しようとすると以下のエラーが発生し、ターミナルが表示されない
リモート接続をフェッチできませんでした
リモート拡張ホスト サーバーへの接続に失敗しました (エラー: WebSocket close with status code 1006)
- ローカルで起動したWordPress（Dockerで起動）やRails（Dockerなし）にもブラウザからアクセスできなくなった
このページは動作していません
localhostからデータが送信されませんでした。
ERR_EMPTY_RESPONSE
バージョン8でESETのGUIが大きく様変わりしたのと、ネット接続などが不安定になるなど別の問題も起きたりしたので切り分けに手こずりましたが、12月になる頃には少なくとも自分のMacbookでのネット接続については落ち着いたようです。
追記（2024/12/03）: そもそもネットに繋がらない場合は以下を試すとよさそうです。
参考: 【解決】macOS Sequoiaアップデート後にWi-Fi（ネット）に繋がらなくなった｜take
🔗 原因
記事冒頭にも書いたように、ESET Cyber Security V8.2.800.0で発生しているバグ情報の中に以下の症状が記載されており、これが原因のようです。
- プリンタなどの通信がファイアウォールで遮断される
- 特定のアプリの通信（ローカルホスト系の通信）がファイアウォールで遮断される
- macOS Sequoia 15.x にアップグレードしてからネットワークに繋がらない
ESET Cyber Security V8.2.800.0 をご利用の環境で通信が遮断される | ESETサポート情報 | 個人向け製品 | キヤノンより
🔗 修正方法
この問題はESETのバグとして認識されているので、最終的にはESET側での修正を待つことになります。
冒頭のサポート情報に沿った正式な回避方法でさしあたって問題を解決できれば、もちろんそれに越したことはありません。
しかしサポート情報によると、それでも解決できない場合は以下を順に試すことになります。
- 「信頼できる第三者アプリケーションへの受信接続を許可する」をオンにする
- ファイアウォールを無効化する（リアルタイムファイルシステム保護機能は引き続き有効）
ファイアウォールの無効化は最後の手段にしたいものです。
私の場合、サポート情報の追加設定である「信頼できる第三者アプリケーションへの受信接続を許可する」設定を有効にしたことで、ファイアウォールを無効化しなくても、いくつかのローカルホストについてはアクセスできるようになりました。アクセスできないローカルホストがある場合の対応方法については後述します。
注意（2024/12/03）
- ここに記載するESET設定のカスタマイズ方法は、基本的には参考にとどめ、本当に必要が生じない限り行わないでください。やむを得ず適用する場合は、自己責任でお願いします。
- ESET側で正式な対応がリリースされた場合は、速やかに本記事のカスタム設定を除去してESET標準の設定に戻すようお願いします。
- 設定 > ファイアウォール > フォールバックルールを開きます。
- 「信頼できる第三者アプリケーションへの受信接続を許可する」をオンにする
（「受信接続を許可する」はオンにしないこと）。
🔗 Webサーバーの公開範囲に注意すること
「信頼できる第三者アプリケーションへの受信接続を許可する」を有効にすると、現時点では同じWiFiにつながっている他のコンピュータから、MacのIPアドレスとポート番号を指定してブラウザでアクセス可能になることは意識しておきましょう。
つまり、たとえばMacを公共のWiFiにつないで作業していると、外部からローカルホストにアクセスされる可能性があるということです。業務で使っているMacでこれを放置すると、何かあったときにコンプライアンスの問題になる可能性もあるので、この設定を行ったら、公共の場所でWebサーバーを起動するときにWiFiを切るなどの対応を行う方がよいでしょう。
個別のWebサーバーの公開範囲について、netstatなどを使って調べました。対応方法は、アプリの種類やカスタマイズ状況によって異なりますので、各自で読み替えてください。
🔗 例: WordPressをDockerで動かす場合（外部アクセスに注意）
以下はDockerコンテナのWordPressをポート80で起動した状態でnetstatを実行したときの結果です。
$ netstat -an -p tcp | grep "\.80 "
tcp46 0 0 *.80 *.* LISTEN
tcp4 0 0 192.168.11.105.55040 38.90.226.12.80 TIME_WAIT
*.80ですべてのネットワークインターフェイスのポート80をリッスンしており、*.*で外部も含むあらゆるIPアドレスからのアクセスを許しているので、MacbookのWiFiのIPアドレスとポート80を指定すれば外部からアクセスできてしまいます。
🔗 例: Railsをdevcontainerで動かす場合（外部には公開されない）
以下はVS Codeとdevcontainer環境でbin/devでRailsサーバーをポート3000で起動してからnetstatを実行したときの結果です。
$ netstat -an -p tcp | grep "\.3000 "
tcp4 0 0 127.0.0.1.3000 127.0.0.1.59999 ESTABLISHED
tcp4 0 0 127.0.0.1.59999 127.0.0.1.3000 ESTABLISHED
tcp4 0 0 127.0.0.1.3000 127.0.0.1.59995 ESTABLISHED
tcp4 0 0 127.0.0.1.59995 127.0.0.1.3000 ESTABLISHED
tcp4 0 0 127.0.0.1.3000 *.* LISTEN
tcp4 0 0 127.0.0.1.59993 127.0.0.1.3000 TIME_WAIT
127.0.0.1.3000（ipv4）はlocalhostのみをリッスンしていることを表します。この場合は外部からMacbookのWiFiのIPアドレスとポート80を指定しても、このWebサーバーにはアクセスされません。
🔗 例: Railsをdipで起動した場合（外部アクセスに注意）
以下はdocker-composeを使いやすくするdipコマンドでRailsを起動してからnetstatを実行したときの結果です。
$ netstat -an -p tcp | grep "\.3000 "
tcp6 0 0 ::1.3000 ::1.60226 ESTABLISHED
tcp6 0 0 ::1.60226 ::1.3000 ESTABLISHED
tcp6 0 0 ::1.3000 ::1.60223 ESTABLISHED
tcp6 0 0 ::1.3000 ::1.60222 ESTABLISHED
tcp6 0 0 ::1.60223 ::1.3000 ESTABLISHED
tcp6 0 0 ::1.60222 ::1.3000 ESTABLISHED
tcp46 0 0 *.3000 *.* LISTEN
*.3000ですべてのネットワークインターフェイスのポート3000をリッスンしており、*.*で外部も含むあらゆるIPアドレスからのアクセスを許しているので、MacbookのWiFiのIPアドレスとポート3000を指定すれば外部からアクセスできてしまいます。
🔗 例: iTerm2で直接Railsを動かす場合（外部アクセスに注意）（追加設定が必要）
以下はiTerm2で（Dockerを使わずに）bin/rails sを実行した場合です。
::1.3000（ipv6）と127.0.0.1.3000（ipv4）はlocalhostのみをリッスンしていることを表します。この場合は外部からMacbookのWiFiのIPアドレスとポート80を指定しても、Webサーバーにアクセスできません。
$ netstat -an -p tcp | grep "\.3000 "
tcp6 0 0 ::1.3000 *.* LISTEN
tcp4 0 0 127.0.0.1.3000 *.* LIipSTEN
今度はiTerm2でbin/rails s -b 0.0.0.0を実行した場合です。今度は*.3000ですべてのネットワークインターフェイスのポート3000をリッスンしているので、冒頭のWordPressの場合と同様に外部からアクセスできてしまいます。
$ netstat -an -p tcp | grep "\.3000 "
tcp4 0 0 *.3000 *.* LISTEN
注意: ただし実際には追加設定を行わないと、ローカル/リモートを問わずブラウザで開こうとしてもアクセスできず、エラーになってしまいます。
この場合、面倒ですがRubyをアプリケーションルールで個別に許可しなければなりませんでした（たぶんPythonやNodeやPHPなどでローカルWebサーバーを動かすときにも同じような作業が必要になると思われます）。
注意（2024/12/03）
- 以下の設定カスタマイズ方法は上記サポート情報には記載されていません。あらかじめご了承ください。
ESET Cyber Security 8のダッシュボードを起動して「ツール > ログファイル」を開き、右上のプルダウンで「ファイアウォール」を開き、アクセスがブロックされたときのアプリケーションを調べます。これでRubyがブロックされていたことがわかります↓。
なるべく避けたいのですが、ログのブロック行を右クリックして「すべての接続を許可する」を選択します↓。
この設定は、ESET Cyber Security 8のファイアウォールのアプリケーションルールに追加されます↓。
複数バージョンのRubyを使う場合はバージョンごとに同様の設定が必要になる点が面倒ですね😢。今のところdevcontainerを使うのが一番楽そうです。
🔗 Command Lines Toolsもアップグレードしよう
本件とは直接関係ありませんが、macOSをアップグレードした後は、念のためCommand Lines Toolsもアップグレードしておきましょう。アップグレード後にRubyのビルド↓が突然失敗するようになって気づきました。
brew doctorを実行して「Command Lines Toolsが古い」と表示されたら↓、表示された指示に従ってCommand Lines Toolsを更新すれば完了です。
$ brew doctor
Warning: Your Command Line Tools are too outdated.
Update them from Software Update in System Preferences or run:
softwareupdate --all --install --force
If that doesn't show you any updates, run:
sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --install
Alternatively, manually download them from:
https://developer.apple.com/download/more/.
You should download the Command Line Tools for Xcode 16.0
参考: Command Line Toolsをアップデートする #Mac - Qiita
関連記事
注意事項（2024/12/03）
本記事を読む前に、以下のサポート情報を必ずお読みください。
参考: ESET Cyber Security V8.2.800.0 をご利用の環境で通信が遮断される | ESETサポート情報 | 個人向け製品 | キヤノン -- 2024/11/29付
今後、上記サポート情報の更新を確認でき次第、本記事の追記・更新を行います。