最近の投稿
- 外部からの到達確認2026-10-03外部からの HTTPS トラブルもあり、nagios に外部から自宅サーバへの到達性チェックを追加。 […]
- https 接続トラブルの対応 (解決)2026-10-02自宅の D-ONU の交換に伴い、https […]
gpon G2425 のパケット流量プラグイン2026-09-30ケーブルテレビの光ルータが入れ替えとなったが、パケット流量を観測していた munin […]
G-2425G-B の HTTPS受信トラブル2026-09-29HTTPS だけ Connection refused DMZ の設定などで Dynamic DNS […]
変な人がいる2026-09-28
外部からの到達確認
外部からの HTTPS トラブルもあり、nagios に外部から自宅サーバへの到達性チェックを追加。
自宅から nrpe で監視している さくらインターネット 上のサーバに以下の設定を追加。
((( 外部サーバ: /etc/nagios/nrpe.d/enabled.cfg )))
# -s 文字が含まれるかチェック(DDNS環境なので文字検索チェック付き)
command[check_tsaitohnet_http]=/usr/lib/nagios/plugins/check_http tsaitoh.net -s tsaitoh.net
command[check_tsaitohnet_https]=/usr/lib/nagios/plugins/check_http --ssl tsaitoh.net -s tsaitoh.net
((( 自宅 )))
define service{
use local-service ; Name of host template to use
host_name .....
service_description TSAITOH_HTTP
check_command check_nrpe!check_tsaitohnet_http
check_interval 1440 ; 1day 確認頻度は低く
retry_interval 60 ; 1h
notification_interval 0 ;
}
# HTTPSチェックは、HTTPSトラブルが解消してから
https 接続トラブルの対応 (解決)
自宅の D-ONU の交換に伴い、https 通信が繋がらなくなった。色々動かない状況から原因を推理していたが、最終的には DMZ と ポートフォワードの組み合わせが原因だったという結論。
自分なりの原因分析 (失敗のまとめ)
丹南ケーブルの光ルータ(GPON G240)の故障に伴い、光ルータ(GPON G2425)に交換となったが、この影響で https がインターネット側から自宅サーバの接続ができなくなった。色々確認する中で、当初は GPON G2425 の外部メンテナンス用の TR069 関連のトラブルを予想していたが、丹南ケーブル側のルータのWAN側メンテナンスポートの問題の可能性があると考察中。(業者の方と情報交換用にメモ)
- 丹南ケーブルでは、D-ONU とインターネット間に何らかのルータ(たぶんFortiGuard)がある。
- FortiGuard Web Filter (記事A)
- https 通信が接続できないトラブルが光ルータの交換でつながったことがある。
- 丹南CATVの光ルータ交換 (記事B)
この点を考えると、今回の原因は、記事A のように GPON G2425 の上にある上流ルータ(たぶんFortiGuard系) で、WAN側のメンテナンス https ポートが開いていて、インターネット側からアクセスすると、Fortigate ? につながろうとする。ただし Fortigate でアクセス可能IPアドレス設定で特定アドレスからしか受け付けないように設定してあるため、Connection Refused になる…. と想定している。記事B の光ルータ交換でつながるようになったのは、収納されているセグメントが変わり、ルータのWAN側メンテナンスhttpsポートが消されているセグメントに移ったためと推定している。
技術さんの訪問確認
丹南ケーブルさんの訪問を受け、現状の確認作業を行い、上記推定の理由の情報交換を行った。
確認ポイント
- 接続までの経路確認
- G2425 は、DMZ 設定で 自宅内ルータ(AirStation)に接続
- 自宅内ルータ(AirStation)は、DMZ設定は使わず、静的ポート変換で(22,25,53,80,123,443,993,465)を、自宅内サーバに流れる。
- 動作検証用に G2425 に 8443 を 自宅内ルータ(AirStation) の 443 にポートフォワードをかけてある。
- 丹南ケーブルの外から、以下を確認
- telnet … 80 で自宅サーバページにアクセス可能。w3m http://tsaitoh.net/ で自宅ページを表示可能。
- telnet … 443 Connection Refused
- telnet … 8443 自宅サーバにアクセス可能。telnet の接続なので 400 エラーが表示されるが、サーバ側がApache2.4.66 / Ubuntu と表示されるので、自宅以外の物につながっている訳ではない。
この結果から、(a) G2425 で 443 が使われている、or (b) G2425 のインターネット側上流ルータが 443 を使っている。この確認としては、丹南ケーブルの内部から telnet … 443 を実行してもらい、つながれば(b)、つながらなければ(a) と原因切り分けが可能なはず。
https 接続は異常なマニアの要求?
https で自宅Webサーバの公開ができない…というクレームは、逸般家庭(異常なマニア)の要求であり、https 接続は諦めて…という論調にならないか心配していた。でも、技術の方との話だと「最近は自宅 IP カメラに https 接続というのはよくある話なので、https はつながる設定は普通」とのお話で、原因究明をちゃんとしてくれそうで良かった。
んで、設定確認で LAN ケーブル抜き差ししてたら、古いケーブルの抜け止めのノッチが折れた。いい機会だし LAN ケーブル買い出しかな。
追記 HTTPS 問題解決 (DMZなし+ポートフォワード)
HTTPS が繋がらないトラブルを改めて見直してみた。
上記の接続で失敗したのは、DMZ を基本として、繋がらない HTTPS だけポートフォワード転送の設定であった。
- (失敗A) – DMZ 転送 – [443 は繋がらない]
- (失敗B) – DMZ 転送 + 443 ポートフォワード – [443 は繋がらない]
ここで、こういった複合設定の相性問題の時は、地道な設定変更が必要。ということで色々組み合わせて実験した結果…
- (成功C) – DMZ 転送なし + 443 ポートフォワード
であればつながることが確認できた。DMZ とポートフォワードの組み合わせが原因だろうか?
原因のまとめ
- G2425のDMZ機能は、HTTPS を正しく通すことができない。
- G2425はDMZ機能とポートフォワードの両方を設定できない。
Gemini でDMZとポートフォワードの処理順序を問い合わせると『一部の特殊な海外製ルータやファームウェアによっては同時に設定すると競合を起こしたり、挙動が変化する場合があります。』だそうな。
ということで、自宅サーバで動かしているプロトコルをポートフォワードで一つ一つ全て記載した。
(2段目のバッファロールータのポートフォワードをコピーし、これに加え ルータ VPN の L2TP/IPsec のポート転送を追記)
| WAN接続 | WAN | LAN | 端末名 | 端末 | protocol | 概要 |
| 1_INTERNET_R_VID_881 | 53~53 | 53~53 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | DNS |
| 1_INTERNET_R_VID_881 | 80~80 | 80~80 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | HTTP |
| 1_INTERNET_R_VID_881 | 443~443 | 443~443 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | HTTPS |
| 1_INTERNET_R_VID_881 | 123~123 | 123~123 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | NTP |
| 1_INTERNET_R_VID_881 | 22~22 | 22~22 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSH |
| 1_INTERNET_R_VID_881 | 993~993 | 993~993 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP/UDP | IMAPS |
| 1_INTERNET_R_VID_881 | 25~25 | 25~25 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SMTP |
| 1_INTERNET_R_VID_881 | 465~465 | 465~465 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSMTP |
| 1_INTERNET_R_VID_881 | 587~587 | 587~587 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | TCP | SSMTP(Submission) |
| 1_INTERNET_R_VID_881 | 500~500 | 500~500 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec(IKE) |
| 1_INTERNET_R_VID_881 | 4500~4500 | 4500~4500 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec(NAT-T) |
| 1_INTERNET_R_VID_881 | 1701~1701 | 1701~1701 | Unknown_xx:xx:xx:xx:xx:xx | 192.168.1.xx | UDP | L2TP/IPsec |
ということで、丹南ケーブルさんにメールに、情報共有しておいた。
gpon G2425 のパケット流量プラグイン
ケーブルテレビの光ルータが入れ替えとなったが、パケット流量を観測していた munin のプラグインが動かなくなる。
Nodejs で実装(Gemini作)
更新前の Nokia G-240 の時には、自分でスクレイピングしてスクリプトを作ったけど、新しい Nokia G-2425 は、セキュリティ対策から色々と事前設定が面倒になってる。そこで、Gemini に「ルータが 192.168.xx.xx にある userid=…. , password=…. の Nokia G2425 の光ルータの munin 用プラグインを作って」と命令したら、作ってくれた。(別日に作らせようとしたら無課金枠を使い切って失敗)
ただ、nodejs なので、処理負荷が高いなぁ…
Lua で実装(Gemini作)
nodejs では、処理負荷が高いので、「 ./gpon.js を Lua で実装して 」と命令してみた。結果として system 時間は減少させることができたけど、若干 lua の方が遅くなった。たぶん、データ取得時に logout 処理が実行されていないため、次回処理でセッション切れの処理がはいっていることも想定できたので、「 処理時間が遅いので logout 処理を追加して 」と命令してみた。(ただし、プログラムの行数は 1.5倍になった)
$ time ./gpon.js ./gpon.js 0.23s user 0.04s system 4% cpu 5.996 total $ time ./gpon.lua (logoutの改良前) ./gpon.lua 0.02s user 0.02s system 0% cpu 6.123 total $ time ./gpon.lua (logoutの処理の改良後) ./gpon.lua 0.02s user 0.02s system 0% cpu 4.551 total
G-2425G-B の HTTPS受信トラブル
HTTPS だけ Connection refused
DMZ の設定などで Dynamic DNS などで外部から自宅サーバのIPアドレスが外部で取れるようになり、サーバ機能が復活してきたけど、HTTPS 接続ができない。外部サーバで telnet … 80 , telnet … 993 などはちゃんと届くのに、telnet … 443 だけ connection closed で接続ができない。
Nokia ルータと TR069 の問題?
Nokia G-2425 443 で Gemini に問い合わせすると、プロバイダ側のルータの遠隔操作の TR069 に使われている可能性が示される。んで、ルータの設定を確認すると、2_TR069_R_VID_1081 という項目が見える。でも、これは、自宅に2つの光電話回線が接続されていた時にこれに似た項目があったはず。今回、5月に1回線を解約した時の設定が残っていて、9/29に設定を修正してもらった。
9/29の解約済み設定の削除作業後、丹南側の設定直後には WAN接続リストは 1_INTERNET_R_VID_881 だけであったが、再起動直後に 2_TR069_R_VID_1081, 3_OTHER_R_VID_981 が復帰している。
- 1_INTERNET_R_VID_881
- 2_TR069_R_VID_1081
- 3_OTHER_R_VID_981
Gemini に問い合わせした結果(どこまで信じればいいのやら)
1. Nokia G-2425 内部での Web 管理画面（HTTPS）衝突
ルーター自身のWeb管理画面（または内部HTTPSサービス）がポート443を使用しているため、外部から443で入ってきた通信を転送せずにルーター自体が横取り（または破棄）しています。
-
切り分け方法:
ポートフォワーディング（Port Forwarding / 仮想サーバー）の設定で、以下のように外部ポートだけを変更して試してみてください。
-
WANインターフェース:
1_INTERNET_R_VID_881 -
外部ポート（WAN Port）:
8443（任意） -
内部ポート（LAN Port）:
443 -
転送先IP: 目的のサーバーのローカルIP（例:
192.168.1.X）
設定後、スマホの4G/5G回線など（Wi-Fiを切った状態）から
[https://64.33.6.246:8443](https://64.33.6.246:8443)にアクセスして接続できれば、原因はルーターの443番ポート競合で確定です。 -
2. ISP（プロバイダ）によるウェルノウンポート（80 / 443）のブロック
一部のプロバイダでは、セキュリティポリシーにより顧客側でのWebサーバー公開を防止するため、グローバルIPを割り当てつつも網元でインバウンドの 80 や 443 通信をフィルタリングして遮断している場合があります。
-
この場合も上記の「外部ポートを
8443などに変更する設定」を行えば通信が通るようになります。
光ルータで、8443→443のポートフォワードを設定したら、telnet … 8443 で接続は確認できた。ブラウザで https://…:8443 を実行したら、BASE_URL の影響かページの表示には失敗した。Gemini のアドバイスからすると、ルータ443と衝突確定。
ケーブルTV D-ONU 交換
今朝、電子レンジと電気ポット併用で部屋のブレーカーをおとしてしまったが、その影響でケーブルテレビの光ルータ(ケーブルテレビ貸与品)が繋がらず。LED状態とかケーブルテレビに伝えたら「故障ですね、交換対応になります！」とな。10年経ってるしトラブルもやむなしだな。だけど、ルータ交換だし自宅IP(動的IPだけどサーバとか動かしていたし実質静的IP状態だった)久々に変わっちゃうな。
今回故障した Nokia G-240W
Nokia G-2425G-B GPON / D-ONU
業者さんが来たら、光ルータ交換前提で現状機器のチェックも一切なく、交換作業が始まる。光ファイバのケーブルの端子の付け替えに苦労していたが、ようやく復旧。新しい光ルータは、Nokia G-2425G-B GPON / D-ONU となった。
業者の方に「ルータ、まあまあ壊れてるんですか？」と聞くと「故障したら交換してます」とのことであった。
背面の設定を直していたら、USB-A のコネクタが無い。温湿度センサーの給電ができないじゃん。でも Web で見つけた資料だと、USB コネクタがある。？？？と思ったけど、設定業者の方がなんか裏に貼ってたな…と思ったら、USB コネクタ部にシール貼って塞いであるじゃん。大電流をとるUSB機器色々あるし、動作が不安定にならないように隠したいんだろうな。温湿度センサーは大した電流じゃないし、シールはがして接続!!
スピード確認
自宅内端末を固定IP管理したかったので、光ルータのDHCPでは自由な設定もできないし、DHCP/Off もできないので内側にWiFi ルータを設置している。このため自宅内WiFiルータだと最高速度が1Gbpsであった。しかしメインPCは2本目の LAN ポートがあるので、光ルータに直結してみた。結果は、最高速度 2.5Gbps であった。これであれば内側 WiFi ルータも更新したくなってきた。
設定の復旧
機器が変更されたし、光ルータの設定の復旧作業
- セキュリティ – DMZとALG で、DMZ有効☑、DMZ IPアドレスに自宅内ルータのアドレスを設定
- Dynamic DNS のスクリプトを実行し、自宅ドメインの対外アドレスを更新
- WiFi の SSID を自宅内用に変更 CATVSTB の通信を WiFi 経由に変更
- SSL 証明書の更新。
ただ、SSL 更新したけど、Dynamic DNS の更新が広まっていないのか、外部からの https 接続はまだ失敗中。Dynamic DNSの更新直後だし、もう少ししてからリトライだな。 - munin で 光ルータのパケット流量を観測するスクリプトが動かなくなってる。
HTTPSが届かない
DMZ の設定などで Dynamic DNS などで外部から自宅サーバに接続ができるようになり、サーバ機能が復活してきたけど、HTTPS 接続ができない。telnet tsaitoh.net 80 , telnet tsaitoh.net 993 などはちゃんと届くのに、telnet tsaitoh.net 443 だけ connection closed で接続ができない。
Nokia G-2425 443 で Gemini に問い合わせすると、プロバイダ側のルータの遠隔操作の TR069 に使われている可能性が示される。んで、ルータの設定を確認すると、2_TR069_R_VID_1081 という項目が見える。でも、これは、自宅に2つの光電話回線が接続されていた時にこれに似た項目があったはず。今回、5月に1回線を解約した時の設定が残っていて、明日9/29に設定を修正するとの話なので、明日には復旧するかな。
readynas の運用開始と DNS,DHCPの多重運用
NETGEAR の ReadyNAS Pro 2 を入手。readynas の 正規 OS は、バージョンが古く debian ベースの でも samba などが古いプロトコルしか使えないので、便利な使い方ができない。
このため、Serial ポートを使って debian/forky をインストール。
サーバを運用していると、ネットワークの設定を間違って DNS, DHCP を止めてしまうと、自宅ネットワークが全滅する。 Raspberry-Pi で DNS セカンダリサーバなどを動かしていたけど、この readynas のサーバで多重サーバ構成にしたい。
DNS のキャッシュサーバ運用
まずは、DNS (bind9)のセカンダリ運用。
((( /etc/bind/named.conf.local )))
zone "tsaitoh.net" {
type slave ;
file "db.tsaitoh.net.slave";
masters {
192.168.xx.yy;
};
};
((( /etc/bind/named.conf.options )))
acl internal-network {
::1;
127.0.0.1;
192.168.xx.0/24;
};
options {
directory "/var/cache/bind";
forwarders { 192.168.xx.yy; };
allow-query { internal-network; };
allow-recursion { internal-network; };
dnssec-validation auto;
listen-on { any; };
allow-transfer { none; };
};
DHCP のホットスタンバイ運用
続いて、DHCP の多重化。最近まで isc-dhcp-server を使っていたけど、kea-dhcp4-server に切り替えていたが、kea-dhcp4-server では、hot-standby 構成を組めるので、設定。2台の DHCP サーバは、8000 ポートで相互に死活状態を確認し、相手が機能していないと、自身が DHCP 処理を行う。
((( /etc/kea/kea-dhcp4.conf )))
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [ {
"this-server-name": "プライマリホスト名", // セカンダリの設定ではセカンダリホスト名を記入
"mode": "hot-standby",
"heartbeat-delay": 1000,
"max-response-delay": 10000,
"max-unacked-clientsets": 5,
"peers": [
{
"name": "プライマリホスト名",
"url": "http://192.168.xx.yy:8000",
"role": "primary"
},
{
"name": "セカンダリホスト名",
"url": "http://192.168.xx.zz:8000",
"role": "standby"
}
]
} ]
}
},
],
これで、メインサーバにトラブルがあっても、自宅内ネットワーク全滅は避けられる。
ベトナムの接続許可
インターンシップ引率でベトナム行き…
夏に備え、出先で自宅サーバ接続ができないのも困るので、GEOIP 情報による FireWall 設定での ipset テーブルで ベトナムの接続許可を行う。
letsencryptのCAA関連のトラブル再び(2)
letsencrypt のドメイン名の更新エラー、確認すると以前発生していた IN CAA … のトラブルが再発している。
状況も同じで、再設定。
snap refresh のトラブル
Ubuntu 26.04 をいれて、snap store につながらなくなり、snap refresh が動かない。
この2日間ほど色々と原因を探していたが、原因不明。マニアックな自宅ネットワークの設定不備を疑って悩んでた。でも、ややこしくない根っこのルータに直結して実験してもつながらない。ということは自宅ネットワークのトラブルじゃない…と確信できたんだけど、そのあと数分後に(何もしてないのに)動き出す。なんだかなぁ…
2026/05/03
Ubuntu への DDoS 攻撃が出ているらしい。snap も影響うけてたんだろうな。
spamhaus のDQSキー取得
spamhaus はパブリックDNSを拒否
自宅メールサーバでの運用で、spamassassin などの設定をしていても、迷惑メールがそれなりに届く。
傾向としては、Google や Amazon のクラウドサーバから、SPF や DKIM を正規に取得した使い捨てドメインから送られてくる。このため、OpenDMARC などを設定してもダメ。Gemini に聞いたら、使い捨てドメインからの RBL のデータベースが得意な、spamhaus を薦めてくれる。
ただ、spamhaus は、以前にも設定したけど問い合わせを拒絶されたので、設定から外していた。改めて確認すると spamhaus は、無料サービスだけど大量の問い合わせをさばききれないので、8.8.8.8 や 1.1.1.1 のような パブリックDNS を経由した問い合わせには、答えを返さない運用をしているらしい。私の拒絶経験もコレが原因。
んで、色々調べると、無償サービスだけどユーザ登録して DQS キーを使えば、パブリックDNS経由での問い合わせでも拒否されないらしい。(最初、ユーザ登録とか嫌いなので、パブリックDNSを使わないキャッシュDNSサーバを立てようか…とも思ったけどシステムが複雑になるだけ)
spamhaus のユーザ登録とDQSキー生成
spamhaus の登録ページにアクセス(Spamhaus DQS Sign Up )し、DQS キーの発行を行う。
postfix に登録
postfix の main.cf の smtpd_recipient_restrictions に 以下のように登録。xxx…xxx の部分に発行した DQS キーを記載する。
((( /etc/postfix/main.cf )))
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client xxxxxxxxxxxxxxxxxxxxxxxxxx.zen.dq.spamhaus.net=127.0.0.[2..11],
check_policy_service unix:private/policy-spf,
permit
追記 2026-05-07 spamhausの効果覿面
spamhaus を RBD に登録してから、効果覿面。使い捨てドメインからのメールがきれいさっぱり止まっていて、最近は spam なしが続いている。
Google 検索
