Lycolog

Windows 11でWindows Updateを行ったところ、色々壊れたので、その対処ログとして残す。

• アップデートした内容
• 発生した問題
  • SSHDに繋がらなくなった
  • LAN内にあるサーバーにIPv6 GUAを利用した疎通が出来なくなった
  • MS Edgeがファイアウォールの許可要求を出すようになった
  • ファイアウォールのルールが極端に減った
• 解決した方法
• 雑感

アップデートした内容

Windows 11 24H2→Windows 11 25H2

OSビルドまでは控えていないため不明。

発生した問題

根本原因の大半はファイアウォールのルールが激減したせいであることが分かった。

SSHDに繋がらなくなった

当該のWindows端末ではLAN内でファイル共有をする目的でSSHDを立てているのだが、これに繋がらなくなった。

原因としては単にファイアウォールのルールが消し飛んでいただけだった。

WindowsにSSHDを立てるでやった方法で穴あけしなおすことで解決した。

LAN内にあるサーバーにIPv6 GUAを利用した疎通が出来なくなった

これはWindowsからLAN内にあるUbuntuサーバーにIPv6 GUAを利用し接続しようとしたところ、接続できなくなった問題だ。WAN側、インターネット上のIPv6 GUAには問題なく接続できた。

これも単にファイアウォールのルールが消し飛んでいただけだったが、どのルールが原因だったのかは特定できていない。

私の環境では基本的にIPv6運用をしているため、例えば自宅でホスティングしている公開MastodonにローカルからアクセスするだけでもGUAを利用しているが、まずここに繋がらなくなった。PINGも通らなかった。但しサーバー側からWindows側へのPINGはFWに穴をあけると繋がった。

ひとまずパケットがサーバーに富んでいるかどうかを見るためにWiresharkで眺めてみることにした。

以下はファイアウォール有効時と無効時でそれぞれPINGを飛ばした時のものだが、有効時はIPアドレスが変換されていることがわかる。

FW有効時	FW無効時

ネットワークにはあまり詳しくないので何とも言えないが、帰りのパケットが届いているように見えることから、IPアドレスの変換が起きることによってステートフルインスペクションが機能不全を起こし、結果として正しく疎通しない状態になっていたのではないかと思う。

ステートフルインスペクションというのはパケットが出ていくときに、戻りのパケットを受け入れるためにポートを開けておく仕組みのことで、ここが塞がっていると戻りのパケットがFWで塞がれて入ってこれなくなる。今回は送信時のIPと、戻ってくるときのIPが異なるため、これが機能しなかったのではないかと考えている。

ステートフルインスペクションについて昔調べていたことがあったので、これはすぐに当たりがついてよかった。調べようとした動機としてはサーバーが待ち受けている場合はポートに穴がないとパケットを受けられないのに、応答はなぜポートに穴が開いてなくても抜けられるのか？と疑問に思ったことがあり、その時に調べていた。

MS Edgeがファイアウォールの許可要求を出すようになった

これは原因がよくわかっていないが、FWを許可してもセキュリティホールにしかならなさそうなので不許可でよいと思う。

ファイアウォールのルールが極端に減った

諸悪の根源はこいつだが、コマンドプロンプトを管理者権限で起動して以下のコマンドを叩くことで解決した。

netsh advfirewall reset

アップデート直後の状態は確かこんな感じだったと思う。なおこの画像は微妙にルールを追加あとに、追加した記憶のあるルールを消しているので内容が正確でない可能性がある。

解決した方法

コマンドプロンプトを管理者権限で起動して以下のコマンドを叩き、SSHDについてはWindowsにSSHDを立てるでやった方法で穴あけし直し。

netsh advfirewall reset

MS Edgeがファイアウォールの許可要求を出すようになった件については対処法が不明なので、とりあえずFWはブロックにしている。

雑感

どうも今回のアップデートでファイアウォールのルールが大きく書き換えられるようで、特にLAN内でIPv6 GUAを利用するときに著しい障害が発生することが分かった。

このクラウド全盛期に自宅サーバーを立てていたり、一般的に避けられがちなIPv6運用を軸にしている人間が少ないこと、ネットがクソみたいなAIコンテンツで溢れていることなどもあり、中々解決に手間取ったが、IPv6を使った自宅サーバー運用者としてIPv6で接続できないのは屈辱的だし、WAN上のIPv6には問題なくつながっており、MSもこんな致命的なバグを長らく放置はしてないだろうから、どこかに抜け穴があるはずと調べていたらどうにか見つけることができた。

調べたといっても、私はネットワークの知識に乏しく、手掛かりになるキーワードを持たないので無料のMS Copilotに聞いただけではあるが、いい収穫が得られた。

参考までに以下のプロンプトを投げた。

Windows 11でWindows Updateをしました。 Updateした端末をクライアントとし、GUAを利用してLAN内のサーバー端末にIPv6接続できなくなりました。

Firewallのルールがすべて削除されていたので、試しにFirewallを無効化すると接続できました。

有効にした場合、LAN内の端末にIPv6 GUA接続した場合に、宛先のIPアドレスを書き換えているようです。これはどうすれば解決できますか？ IPアドレスが書き換えられるため接続ができないものとみられます。

例えば2400:4153:8f01:c800:c14b:3f7a:2b54:353aに接続しようとするとff01::1:ff54::353aに書き換えられます。ファイアウォールを無効化した場合、書き換えられません。

確認時のApache2のバージョンはApache/2.4.58 (Ubuntu)

• Apache2のインストール
• 公開ディレクトリを触りやすくする
• mod_rewriteやmod_cgiを使えるようにする
• PHPを使えるようにする

Apache2のインストール

sudo apt -y install apache2

公開ディレクトリを触りやすくする

公開ディレクトリの所有者はデフォルトだとroot:rootで、そのままでは扱いづらいため自分自身でも手軽に扱えるように権限を調整する。

# 公開ディレクトリを見たりいじる為に自分をwww-dataに入れる
sudo usermod -aG www-data <自分のユーザー名>
# 公開ディレクトリを扱いやすくするためwww-data:www-dataに変える
sudo chown -R www-data:www-data /var/www
# 公開ディレクトリを扱いやすくするためにグループに全権限を付与する
sudo chmod -R g+rwx /var/www

mod_rewriteやmod_cgiを使えるようにする

CGIの実行に必要なPerlなどのランタイムは必要に応じて別途入れておく。PHPは一般的にCGIとして実行しないため、次項の方法で動かせるようにする。

sudo a2enmod rewrite
sudo a2enmod cgi

sudo service apache2 restart

PHPを使えるようにする

バージョンの部分は適宜書き換える。PHP本体をインストールしていない場合は別途インストールしておく（依存解決で勝手にインストールされるかもしれないが）

sudo apt install -y libapache2-mod-php8.3
sudo a2enmod php8.3

sudo service apache2 restart

完全には解消していないが、とりあえず日本語が打てるようになったので記す。

• 確認環境
• 起きていた事象
• 状況
• 対処法
• あとがき

確認環境

Ubuntu 24.04.3 LTS

起きていた事象

Ubuntu Serverとして導入した環境をUbuntu Desktop(GNOME)に置き換え、Xubuntu Desktopにマイグレーションしたところ、Ubuntu Desktopでは問題なかった日本語入力ができなくなった。

状況

IbusとMozcが自動起動せず、手動で起動させても日本語が打てず、systemctl --user show-environmentを叩いたときに以下の内容が出る状況だった。

HOME=/home/hoge
LANG=ja_JP.UTF-8
LOGNAME=hoge
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
SHELL=/usr/bin/zsh
USER=hoge
XDG_RUNTIME_DIR=/run/user/1000
GTK_MODULES=gail:atk-bridge
QT_ACCESSIBILITY=1
XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DISPLAY=:10.0
GSM_SKIP_SSH_AGENT_WORKAROUND=true
SSH_AUTH_SOCK=/tmp/ssh-80h84ldKtdNU/agent.2702
XAUTHLOCALHOSTNAME=

参考までに正常に動作する環境では以下の出力となる。こちらはUbuntu Desktop→Xubuntu Desktopと辿ってきており、Server由来要素がない環境だ。

HOME=/home/hoge
LANG=ja_JP.UTF-8
LOGNAME=hoge
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
SHELL=/usr/bin/zsh
USER=hoge
XDG_RUNTIME_DIR=/run/user/1000
GTK_MODULES=gail:atk-bridge
QT_ACCESSIBILITY=1
XDG_DATA_DIRS=/usr/share/xfce4:/usr/share/xubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop
CLUTTER_BACKEND=x11
CLUTTER_IM_MODULE=ibus
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DEBUGINFOD_URLS=$'https://debuginfod.ubuntu.com '
DESKTOP_SESSION=xubuntu
DISPLAY=:0
GDMSESSION=xubuntu
GDM_LANG=ja_JP
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GSM_SKIP_SSH_AGENT_WORKAROUND=true
GTK_IM_MODULE=ibus
GTK_OVERLAY_SCROLLING=0
IM_CONFIG_PHASE=1
LANGUAGE=ja_JP
PWD=/home/hoge
QT_IM_MODULE=ibus
QT_QPA_PLATFORMTHEME=gtk2
SHLVL=0
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
XAUTHLOCALHOSTNAME=
XAUTHORITY=/home/hoge/.Xauthority
XDG_CONFIG_DIRS=/etc/xdg/xdg-xubuntu:/etc/xdg
XDG_CURRENT_DESKTOP=XFCE
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/hoge
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=xubuntu
XDG_SESSION_TYPE=x11
XMODIFIERS=@im=ibus
_=/usr/bin/dbus-update-activation-environment

対処法

/etc/environmentに以下の内容を追記し、OS起動ごとにWhinsker MenuからIbusの設定を叩いて起動させることにした。自動起動の実現は結構面倒そうだったので試していない。

GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus

あとがき

本来あるべき姿で起動させたいが方法が全くわかっていないのが厳しい…。何より環境変数が圧倒的に足りていないので、色々不都合が起きてそうだ。

まぁ当該端末をデスクトップユースで使うことは滅多にないのでいいっちゃいいのだが…。

なんか昔のやり方が使えなくなってたので調べたメモ。

• 確認環境
• 手順
• 検証ユーザーの作成
• フロントエンドのビルドとサーバー起動
• トラブルシューティング
  • localhostではアクセスできるが、マシンのホスト名やhoge.testのようなローカルドメインでアクセスできない
  • ActiveRecord::PendingMigrationErrorなど、ActiveRecord関係のエラーが出る
  • Unable to load application: NameError: uninitialized constant LetterOpenerWebというエラーが出る
• あとがき

確認環境

手順

DEVELOPMENT.md#dockerの手順通りにやると行ける。

docker compose -f .devcontainer/compose.yaml up -d
docker compose -f .devcontainer/compose.yaml exec app bin/setup
docker compose -f .devcontainer/compose.yaml exec app bin/dev

コンテナへのアタッチ方法

# 方法1
docker compose -f .devcontainer/compose.yaml exec app zsh

# 方法2
cd .devcontainer
docker compose exec app zsh

VSCodeがあるならDockerやRemoteほげほげ系の拡張を使い、devcontainer-appにAttach Shellしてもよい。

検証ユーザーの作成

1. 次のコマンドでユーザーを作る

   ./bin/tootctl accounts create hoge --email hoge@example.com --confirmed
   

2. ユーザーの承認を行い、必要に応じてパスワードを使いやすいものに変更する

   rails console
   user = Account.find_by(username: 'hoge').user
   user.approve!
   # PW変更ここから
   user.password = 'password'
   user.skip_confirmation!
   # PW変更ここまで
   user.save!
   quit
   

フロントエンドのビルドとサーバー起動

bin/rails assets:precompile
bin/dev

トラブルシューティング

localhostではアクセスできるが、マシンのホスト名やhoge.testのようなローカルドメインでアクセスできない

.env.developmentにALTERNATE_DOMAINS=hoge.testの行を追加することで他のドメインでもアクセスできる。

この設定があるとMastodonを別環境で動かしててリモートからドメインアクセスする場合に便利。

ActiveRecord::PendingMigrationErrorなど、ActiveRecord関係のエラーが出る

コンテナの中でrails db:setupを叩くことで解決する。

Unable to load application: NameError: uninitialized constant LetterOpenerWebというエラーが出る

リポジトリルートにあるdocker-compose.ymlを使うと発生するので、.devcontainer/compose.yamlを使う事で解決する。

あとがき

検証用にバニラなMastodon環境が欲しくて作ってみたが昔と変わっていて地味にハマった…。

Windows標準のOpenSSHを利用してSSHDを立てる方法。

SSHサーバーをインストールする

20分くらいかかるので、気長に待つ。

# 有効なバージョンの確認
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
# インストール
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

SSHDサービスを構成する

# SSHDサービスの開始
Start-Service sshd
# 自動起動に設定
Set-Service -Name sshd -StartupType 'Automatic'

# 構成状況の確認
Get-Service -Name sshd
(Get-Service -Name "sshd").StartType

SSHDを鍵認証できるように設定する

%programdata%\ssh\sshd_configに設定ファイルがあるので、これを触る。

Ubuntuと同じOpenSSHであるため、設定方法は基本的に過去に書いたSSHDの設定方法と同じだが、管理者であればAuthorizedKeysFileのコメントを外す必要はない。

管理者である場合、authorized_keysはadministrators_authorized_keysというファイル名にして%programdata%\sshに置く。

書き換えたらRestart-Service sshdで再起動する。

上手く繋がらない場合は、Stop-Service sshdでサービスを止めたうえでsshd.exe -ddd -eで直に起動するとデバッグログが見れるので参考にする。

ファイアーウォールへの穴開け

1. コントロールパネル→Windows Defender ファイアウォール→詳細設定を開く
2. 受信の規則にOpenSSHが登録されているが、ポート番号が変更不能なため削除する

3. 次のコマンドを流し、規則を作りなおす

   New-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort <ポート番号>