停電作業で苦労した話をご報告です。
今回の対象はSoftEtherのVPN Serverとして利用しているRaspberryPi3のRaspberryPi OS Bookwormで発生しました。
現象の詳細
停電を伴う工事が予定されたため、SoftEtherのVPN Serverとして利用するRaspberryPi3（OSはRaspberryPi OS Bookworm＝Ver.12）を工事前にシャットダウンし、工事完了後の復電がされたところで改めてサーバを起動する、というよくある停電時のメンテナンス作業にて発生しました。
シャットダウン前まで正常に動作していたのですが、工事後に復電してからサーバを起動したところ、SoftEtherによるVPN接続ができない状態になっていました。
pingの実行結果は、RaspberryPi自分自身（ループバックアドレス127.0.0.1や自IP）へのpingは成功しますが、RaspberryPiから他のPCやルータへのpingは失敗します。また、他のPC⇒RaspberryPiへのpingも失敗します。
結論
結論から述べると、bullseyeやBookwormへのアップグレード（Ver.10 buster以前のOSからアップグレードしたもの）によって、
eth0のNIC名がenxx000xx000x00のようなランダム名称に変更されたことが原因でした。
full-upgradeでBookwormへのアップグレード後に再起動していない場合には発生する現象だと思います。（SodtEtherのブリッジにeth0が登録されている場合、eth0の名前が変わってしまうことによる現象）
同じようなことは過去の記事にもありましたので参考に掲載しておきます。
※参考にした過去記事のリンク
RaspberryPiでSoftetherで必須なtapデバイス
https://blog.treedown.net/entry/2016/09/10/010000
続・RaspberryPi3のtapデバイス on Softether
https://blog.treedown.net/entry/2016/09/30/010000
Raspberry Pi OSをbusterからbullseyeへアップグレード
https://blog.treedown.net/entry/2024/03/19/010000
記憶の限り再現したメモ
いくつか調べて試して、のように多少回り道をしていたので、全ての記録を残していないのですが、関係しそうな部分も含めて作業実施時のメモをこれ以降で残していきます。
再起動後、通信ができなくなっていました。（pingが双方向で通信通らない）ここからスタートです。
いくつか調べてみたところ、eth0のNIC名が変わっていたことが分かりました。
この写真、手ぶれしているせいでまったく判別できません。以下、一部修正したifconfigの実行結果です。（ip -aでも同じ表示が出るはず）
※なお、実機で出力したものと内容を変更しています。IPなどのアドレス値は実際の内容と異なります。
--------------------------------------------------------------
ifconfig実行結果
--------------------------------------------------------------
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.00.110 netmask 255.255.255.0 broadcast 192.168.00.255
inet6 fe80::1c26:0000:0x00:0ee0 prefixlen 64 scopeid 0x20<link>
ether 00:ac:ff:ff:ff:00 txqueuelen 1000 (イーサネット)
RX packets 1287950 bytes 385380419 (367.5 MiB)
RX errors 0 dropped 66655 overruns 0 frame 0
TX packets 1917116 bytes 1531263833 (1.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enxx000xx000x00: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.00.31 netmask 255.255.255.0 broadcast 192.168.00.255
inet6 fe80::fd76:0000:0x00:0ee0 prefixlen 64 scopeid 0x20<link>
ether b8:27:ff:ff:ff:01 txqueuelen 1000 (イーサネット)
RX packets 3458881 bytes 1737017043 (1.6 GiB)
RX errors 0 dropped 98856 overruns 0 frame 0
TX packets 3059542 bytes 1837128258 (1.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (ローカルループバック)
RX packets 1252 bytes 122915 (120.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1252 bytes 122915 (120.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap_sfteth: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::2ac:0000:0x00:0ee0 prefixlen 64 scopeid 0x20<link>
ether 00:ac::ff:ff:ff:11 txqueuelen 1000 (イーサネット)
RX packets 1207998 bytes 278163887 (265.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2200048 bytes 1384397584 (1.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27::ff:ff:ff:11 txqueuelen 1000 (イーサネット)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
--------------------------------------------------------------
以前eth0で設定していたNICはenxx000xx000x00となっていました。
これはDebianでもあったOSのfull-upgrade実施でのアップデートで恐らく仕様変更となった影響で同じようなことがあったことを思い出しました。
（前述の参考にした過去記事URL参照）
そのためSoftEther構築時にはbr0にeth0とtapデバイス（前述の「tap_sfteth」がtapデバイス、SoftEtherで作成）を追加して通信が成立していたのが、成立しなくなったと考えられました。
※ちなみにifconfigで確認したNIC情報ではIPが想定通り（以前と同じ）の割り当てになっていました。（後述）
コマンド「brctl show br0」で確認してみます。
--------------------------------------------------------------
root@softether:/home/user# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.00acff80f855 no tap_sfteth
--------------------------------------------------------------
このようにtapデバイスがbr0に登録（L2接続）されているのですが、元々追加されていたeth0はNIC名がenxx000xx000x00と変化した影響で存在していない状態になっています。
※tapデバイスしかbr0に存在していない状態なので、LAN（以前のeth0）への通信の口がないことで、通信不可になっていると思われました。
解決方法は（恐らく）NIC名をenxx000xx000x00からeth0に戻すか、
はたまたeth0と同じようにNIC：enxx000xx000x00をbr0に追加するか、このどちらかだと考えられました。
今回は「enxx000xx000x00」をbr0に登録することにします。
コマンドは、
# brctl addif br0 enxx000xx000x00
これで追加すると、
--------------------------------------------------------------
# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.00acff80f855 no enxx000xx000x00
tap_sfteth
--------------------------------------------------------------
こう変化します。これはつまり何をしたかというと、br0の接続先としてenxx000xx000x00とtap_sftethの両方が接続されていると言う状態を示しています。br0が内部でのL2接続（HUBにLANケーブル繋げて通信できるようにする動き）を示しているので、この状態じゃないと、SoftEtherはVPN経由で接続したあと、ローカルエリア内への通信ができない、ということになります。
上記で他のPCからRaspberryPiのSoftEther用NICにpingしていた画面に変化が起きました。
分割されたうち、上のping画面はbr0に設定してあるIPへのping、下のping画面は元々eth0で指定されていたNICに割り当てられたIPアドレスへのpingを試行していた画面です。
赤線を境目にして通信が復旧しているのですが、この赤線のタイミングで「# brctl addif br0 enxx000xx000x00」によるbr0へNICを追加しています。
このあとSoftEtherでVPN Clientから通信テストを実施し、無事VPN接続ができることを確認できました。
こうして問題は解決しました。
