検索条件
全2件
(1/1ページ)
お知らせ
現在サイトのリニューアル作業中のため、表示が崩れているページが存在することがあります。
投稿日：
鍵束をいい感じに運用するでは、カラビナ付きのキーホルダーを使い、自転車の鍵を着脱可能にして管理しやすくしたり、旅先で得たコインロッカーの鍵を管理したりしたことを書いたが、今回はその続きとして、カバンの運用整備について書いていく。
すべてのカバンに鍵束管理システムを装着できるようにした
普段のバッグ、PCバッグ、登山ザック、トートバッグに至るまで全てのカバンに例の鍵束システムを実装した。
悩んだのはトートバッグだった。これまでトートバッグには鍵を裸で放り込んでおり、特に自転車のかごに入れて運んでいるときに紛失リスクが高かった。しかしこれは次のグッズによって解決した。
それは第一鋼材のマーキー・ストラップだ。このグッズはプラスチック製のバックル付きのベルトで出来ていて、トートバックに後からつけることが可能な便利な品だ。
しかも鍵をつけることが想定されているので一般的なベルトと比べると短くうえに、小さく使いやすい。鍵以外にもキーホルダーをぶら下げてもよさそうだし、これに缶バッジやピンバッジをつければカバン本端を傷めずにデコレーションできる可能性もあり、色々便利そうな一品である。
神戸ではコーナンで買うことができた。元々キーホルダーのリングを探している時に偶然見つけて、それ以来これを使い続けている。
カバン装備の共通化
複数カバンを持っていると、別のカバンを使ったときにあれがない、これがないというのが起きがちなので、必需品は共通化することにした。
但しトートバッグは、その形状や特性から対象外にしている。そもそもトートバッグをメインバッグにして長時間行動することがないためだ。鍵さえ紛失できずにぶら下げられていればいい。
内容としては普段のバッグ、PCバッグ、登山ザックの全てに靴ベラ、眼鏡ケース、ティッシュ、絆創膏、頭痛薬を入れている。
靴ベラは靴を長持ちさせるための必需品だ。ないとすぐに傷んでしまう。
眼鏡ケースはバスや電車で寝るときに重宝する。眼鏡をかけたままもたれ掛かって寝ているとフレームが歪んだり傷がついてしまう。私の使っている眼鏡は特殊なフレームで、替えが見つからないためその保護のために持ち歩いている。他にも眼鏡をはずす様々なシーンで活躍する。
かつて眼鏡ケースを持ってこなかったばかりに寝られなかったり、変なところにおいてた製で落としてしまったなどがあったため、眼鏡ケースも重要なアイテムだ。
ティッシュについては私が年中鼻炎なので必須である。
絆創膏もあると便利だ。若い時はまだいいが、年をとってくると怪我の直りが悪いのであるとよい。
そして最後の頭痛薬だが、個人的に頭痛持ちということもあるが、頭痛薬は鎮痛剤でもあるため、登山で下山するときに足を痛めてしまったときにも重宝する。足が痛いので山岳救助を呼ぶなんてやっていたら破産してしまう。
登山以外にも旅行先で割と歩くので、足が痛くなった時によく使っている。
投稿日：
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がファイアウォールの許可要求を出すようになった
これも単にファイアウォールのルールが消し飛んでいただけだったが、どのルールが原因だったのかは特定できていない。
ファイアウォールのルールが極端に減った
諸悪の根源はこいつだが、コマンドプロンプトを管理者権限で起動して以下のコマンドを叩くことで解決した。
netsh advfirewall reset
アップデート直後の状態は確かこんな感じだったと思う。なおこの画像は微妙にルールを追加あとに、追加した記憶のあるルールを消しているので内容が正確でない可能性がある。
すべてを解決した方法
コマンドプロンプトを管理者権限で起動して以下のコマンドを叩き、SSHDについてはWindowsにSSHDを立てるでやった方法で穴あけし直し。
netsh advfirewall reset
雑感
どうも今回のアップデートでファイアウォールのルールが大きく書き換えられるようで、特に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に書き換えられます。ファイアウォールを無効化した場合、書き換えられません。