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に書き換えられます。ファイアウォールを無効化した場合、書き換えられません。

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 <ポート番号>
   

Windowsに入っている古くて使いづらいPowerShellをアップグレードするところから始める。

1. Powershell 7.xを入れる
2. PowerShellを管理者権限で起動
3. Set-ExecutionPolicy RemoteSignedを流す
4. hoge.ps1などの名前で適当にファイルを作り、C:\Program Files\PowerShell\7\pwsh.exeに関連付けする