Lycolog

ステートフルインスペクションというのはパケットが出ていくときに、戻りのパケットを受け入れるためにポートを開けておく仕組みのことで、ここが塞がっていると戻りのパケットが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に書き換えられます。ファイアウォールを無効化した場合、書き換えられません。

コメント（0件）

新しくなったトレールウォーカーワイドがキツくて履けなかった

投稿日：2025/10/23ジャンル::買い物

mont-bellの登山靴の一つにトレールウォーカーという靴があり、幅広版にはワイドという名前がついている。

これが最近リニューアルされたようで、だいぶ靴の形が変わってしまって履けなくなった話。

以下はリニューアル後のトレールウォーカーワイド（品番：1129773）と、リニューアル前のトレールウォーカーワイド（品番：1129652）の比較だ。青い方がリニューアル後、灰色がリニューアル前。

リニューアル後はつま先が曲がっており、つま先の高さも低くなっており、真ん中の紐が横断している隙間も1cmほど狭くなっているように思う。これによって私の幅広甲高な足だと指が圧迫され、指の第一関節が押し付けられ、かなり苦しかった。

試着の時はそこまで気にならなかったが、実際に路上を歩くと五分で違和感を覚え、数時間歩くと痛みで歩行が困難になるほどだった。

余談だがワイドでない方にも同様の変更がありそうだった。

リニューアル前のトレールウォーカーワイドは通常店舗では手に入れることが出来ないが、公式通販やアウトレットショップには型落ち品として在庫があるため、手持ち品を更新する場合はこちらを買うと良い。また、公式の店舗在庫はかなりリアルタイムに更新されているようで、購入して30分後に確認した時には既にサイト上で店舗在庫が消えていたので、店舗で購入する場合は有力な指標になると思う。恐らく目の前の客が今買った以外以外のケースでは概ねアテになるのではなかろうか。

コメント（0件）

IPv6アクセス比率集計結果

投稿日：2025/10/23ジャンル::サイト運営ネットワーク::IPv6

Google Analyticsを廃止してMatomoを導入してから集めていたIPv6のアクセス比率を集計した結果をメモしておく。

集計期間は2025/08/17～2025/10/21。

サイト	IPv6ビジット	IPv4ビジット
lycolia.info	56 (55.0%)	77 (45.0%)
ブログ (blog.lycolia.info)	2,018 (43.4%)	2,644 (56.7%)
ECO-Wiki (eco.lycolia.info/wiki)	7,946 (40.5%)	11,291 (59.4%)
ツールサイト (tool.lycolia.info)	13 (65.0%)	7 (35.0%)
合計	10,033 (41.7%)	14,019 (58.2%)

以上の結果からIPv6は約四割、v4は約六割ということが分かった。また最もアクセスがあるのはECO-Wikiで、ツールサイトにはほぼアクセスがないことも明確になった。まぁツールは私が使えればいいので仕方ないね。

lycolia.infoは突出してIPv6のアクセスが多いが、実数が少なすぎるので余りアテにならない。ただ恐らく、リンク元の特性的に、ITオタク周りのアクセスが多いことが想定されるため、この結果はある程度妥当かもしれない。ツールサイトもそういう人が興味を持って踏んでるのだとしたら納得だ。ブログも技術記事がある関係で比率が高い可能性がある。

逆にECO-Wikiは比較的一般向けのサイトなので比率が少なくなっていると思った。

あとがき

まだまだIPv4の環境は多く、IPv6シングルスタックへの移行はやや戸惑うレベルだ。GitHubのWebhookもIPv4だったりするので、しばらくはデュアルスタックで運用していくのが無難だろう。

現状さくらのレンタルサーバー上にある資源を自宅サーバーにフル移行する場合、DNS側の制約でマルチドメインのDDNSが面倒な問題があるため、専用のスクリプトを作る必要が出てきそうだ。

これは契約しているDNSサーバーのDDNSが1回に1レコードしか更新できず、レートリミットが60秒に1回という面倒な仕様なため、ドメインが複数あると厄介なのだ。現状Mastodonだけが自宅サーバーにある状態なのでどうにかなっているが、どうにかして対処しないといけない。

契約しているDNSサーバーにはDDNS API以外にも、DNSレコードを全部書き換えられるAPIがあり、こちらは1回に複数レコードを触れるため、比較的レートリミットを気にする必要がなくなる。なので、これを使って自力で書き換えるスクリプトを組めばDDNS APIのレートリミットは無視できるようになる。まぁ、こっちのAPIはレートリミットが緩いので何度でも叩けるのだが、バルク編集できるAPIを何度も叩く意味もないので…。

これとは関係なく、将来的には自宅サーバー側に権威DNSを立てて、レジストラのDNSサーバー側にはNSレコードだけというのもやってみたさがある。この場合、ドメインの追加や削除で一々レジストラの管理画面にアクセスする頻度が減らせ、管理が楽になるメリットがありそうだし、レジストラのDNSでは実現できないことが出来るようになる可能性もあるだろうから面白いかもしれない。

コメント（0件）

Ubuntu 24.04.3 LTSにApache2を入れる

投稿日：2025/10/21OS::Linux::Ubuntuミドルウェア::HTTPD::Apache2

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

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

コメント（0件）

nginxからApache2のバーチャルホストにいい感じにリバプロする方法

投稿日：2025/10/17ミドルウェア::HTTPD::nginxミドルウェア::HTTPD::Apache2ネットワーク::HTTP

nginxでhttps://example.comを受けて、https非対応のApache2にリバプロし、Apache2側でもhttps://example.comでアクセスされているように振舞わせる方法。取り敢えず最低限こんだけあると無難だろうという内容。

Apache2（後段）の設定

/etc/apache2/ports.conf

80や443を開けるとnginxと衝突するため、適当にずらしておく。

Listen 8080

/etc/apache2/sites-enabled/001-example.conf

ServerNameは外側と同じものにする。

<VirtualHost *:8080>
        ServerName example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/example-error.log
        CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

nginx（前段）の設定

/etc/nginx/nginx.conf

httpセクションにupstream apacheを追記することで、conf.d/配下の設定ファイルから共通的に参照できるようにする。同じことを複数の設定ファイルに書くと構文エラーで起動しなくなる。

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;

    upstream apache {
      server [::1]:8080;
    }

    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/example.conf

ここでは/etc/nginx/nginx.confで設定したupstreamにプロキシする設定を作っている。

proxy_set_header Host $host;はnginxが受けたホストヘッダをそのままApacheに飛ばすことで、Apache側がバーチャルホストでルーティングできるようにしている。Apacheとnginxで別々のホスト名にすることもできるが、そうした場合、Apache側はApache側で定義したホスト名で動作するため、CGIなどのスクリプトを動かすときに支障があるうえ、Apache側のホスト名をhostsに書かないと疎通できないこともあり、手間なので基本的に前段のドメインに合わせておくのが無難だ。

proxy_set_header X-Real-IP $remote_addr;はnginxにアクセスしてきたクライアントのIPをApacheに渡すための設定。そのままだとnginxのIPが渡ってしまう。

proxy_set_header X-Forwarded-Proto $scheme;もホストヘッダの転送と似ていて、nginxが受けたプロトコルスキーマをApacheに飛ばすための設定。こうしておくとApache側はhttpで受けているのに、httpsでアクセスされたものとして認識させることが出来るため、プロトコルスキーマ付きでURLを生成するCGIがいるときに都合がいい。単にスキーマを誤魔化しているだけなので実際は暗号化されていない。

server {
  listen [::]:443 ssl;
  server_name  example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  access_log   /var/log/nginx/example.access.log;
  error_log    /var/log/nginx/example.error.log;

  location / {
    proxy_pass http://apache/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

余談：HTTP通信に用いられるHOSTヘッダーについて

HTTP通信で利用されるドメインは単にHOSTヘッダーにドメインを書いているだけなので、以下のようなことをするとhostsを書かなくとも疎通できる。

curl -H "HOST: lycolia.info" http://"[2403:3a00:101:13:133:167:8:98]"

これは一般的なHTTPクライアントの仕組みとして、まずドメインをDNSに問い合わせ、IPを取得したのち、ドメインをホストヘッダーに載せてIPアドレス宛にHTTP要求を出しているからだと思われる。

hostsの書き換えができない環境で、任意のドメインに対してHTTP要求を出したい時にも重宝するので、覚えておくと何かと役に立つ。

コメント（0件）