更新日:
投稿日:

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

アップデートした内容

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

更新日:
投稿日:

なんか突如としてGitHubにHTTP経由で繋ぐのが面倒くさくなったのでSSHで繋げるようにしたときのメモ。

確認環境

  • Windows 11 Pro 25H2
  • Ubuntu 24.04.3 LTS
  • RLogin 2.30.8

やり方

SSH鍵の作成

  1. RLoginを開き、サーバーに接続→新規→サーバー→プロトコルを開く
  2. 認証キーボタンを押しED25519辺りで適当な名前で鍵を作成する
  3. 適当な場所に秘密鍵をエクスポートする。ここでは便宜上github.secとする
  4. 鍵を右クリックし、公開鍵をコピーして、どっかにメモっておく

GitHubへの登録

  1. GitHubを開き、アカウント設定に移動、SSH and GPG keysを開く
  2. SSH keys→New SSH Keyを開く
  3. Titleに適当な名前を設定
  4. Key typeはAuthentication Keyにする
  5. RLoginで作った
  6. コピーした公開鍵をKeyに貼り付ける
  7. Add SSH keyボタンを押す

SSH Configを書く

Windowsの場合

ここではWindowsのSSHクライアントを利用する。

  1. Gitに利用するSSHクライアントの設定をする
    git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"
    
  2. 作成したSSH鍵をC:/Users/<ユーザー名>/.ssh/に置く
  3. C:/Users/<ユーザー名>/.ssh/configを開き、次の内容を記述
    Host github.com
        User <ユーザーID>
        Hostname github.com
        IdentityFile C:/Users/<ユーザー名>/.ssh/github.sec
    
    パス表現に%USERPROFILE%は通用しないので注意
Ubuntuの場合
  1. 作成したSSH鍵を~/.ssh/github.secに置く
  2. chmod 600 ~/.ssh/github.secとかして自分しか見れないようにする
  3. ~/.ssh/configを開き、次の内容を記述
    Host github.com
        User <ユーザーID>
        Hostname github.com
        IdentityFile ~/.ssh/github.sec
    

既存のリポジトリをSSH対応にする

ここではoriginがリモートであるとして進める。

  1. git remote -vでリモートリポジトリの状況を確認
  2. git remote remove originでHTTP通信になってるのを消す
  3. git remote add origin git@github.com:Hoge/piyo.gitでSSH通信に書き換える
  4. git fetchが通ればOK
投稿日:

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