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
spam が google などのクラウドばっかり
自宅サーバへの spam は、spamassasin などでかなり除去できるようにしてあるけど、それでも相変わらず届いている。送り元の IP アドレスを調べて 完全拒否などもしているけど、それでも届くのか。
送り元の確認
あらためて、送り元を確認したら、google クラウドサーバとか amazon クラウド。IPアドレスでは消せないなぁ。
$ cd ~/Maildir/.Junk/cur
$ grep "Received: from" * \
| grep -v 127. \
| awk -F [][] '{print $2}' \ [,]を区切り文字として真ん中を取り出す
| sort | uniq -c | sort -r
6 202.238.198.26
1 54.169.135.62
1 52.76.242.183
1 35.236.54.228
1 35.236.40.141
1 35.226.131.57
1 34.96.185.118
1 34.176.225.88
1 34.163.22.216
1 34.155.225.82
:

OpenDMARC fail で消せばいい
メール確認してたら、OpenDMARC が fail 返しているじゃん。こんなの Reject されてると思ってたけど、
“Authentication-Results: OpenDMARC; dmarc=fail (p=reject dis=none) header.from=monex.co.jp”
opendmarc.conf を確認したら、デフォルトのままで reject してなかった。ということで reject するように設定変更。
((( /etc/opendmarc.conf ))) # 認証に失敗したメールを拒否するように変更 RejectFailures true $ sudo systemctl restart opendmarc
職場からのメールは、fukui-nct.ac.jp 発信のメールが、fukui.kosen-ac.jp で届くので、dmarc=fail で失敗判定なんだけど (p=none) なので、普通に届く。
んで、自宅ドメインは…. p=quarantine 「隔離」設定になってるな。そろそろ reject「拒否」にしてもいいかも。
squidからtinyproxyに移行
Squid が遅い
Poicy Routing を導入して proxy 経由のアクセスを別ポートにすることができたけど、squid で動かしている中で、speed test を実行すると、何もなしで 1Gbps 近くでるものの、Proxy 経由にすると squid の性能が低いためか、10Mbps 程度しかでない。
tinyproxy をインストール
あまりにも遅いので、Squid 以外の Proxy サーバを探す。proxy による caching 効果は最近はほとんどないので、proxy パケットを捌くだけのものを調べると HAproxy が高性能らしいけど、reverse proxy 用途で設定がややこしそう。tinyproxy も候補にあがったので、こちらを導入
((( tinyproxy をインストール ))) $ sudo apt remove squid $ sudo apt install tinyproxy ((( /etc/tinyproxy/tinyproxy.conf ))) User tinyproxy Group tinyproxy Port 3128 # squid 互換の proxy ポート Bind 192.168.1.51 # outgoing ポートを 専用ポートにする Timeout 600 DefaultErrorFile "/usr/share/tinyproxy/default.html" StatFile "/usr/share/tinyproxy/stats.html" LogFile "/var/log/tinyproxy/tinyproxy.log" LogLevel Info PidFile "/run/tinyproxy/tinyproxy.pid" MaxClients 100 Allow 127.0.0.1 Allow ::1 Allow 192.168.11.0/24 ViaProxyName "tinyproxy"
policy-routing で Squid を別ポートに振分け
自宅のプロバイダ接続のルータは、上流2.5Gbps だけど、DHCPなどの設定の自由度が低いため、内側に WiFi ルータを置いた2段構成。ただし、上流ルータの LAN ポートが 1Gbps なので、2.5Gbps を活かせていない。
自宅サーバを使わない catvstb は、上流ルータの WiFi ポートを指定することで、内側 WiFi を使わないようにして、少しはトラヒックを分割した。
でも、さらなるトラヒックを活かすべく、内側ルータ内のサーバに2本目の LAN ポートを設け、内側 WiFi ルータを経由せずに上流ルータにつながるようにして、Squid の Proxy サーバのトラヒックだけこちらに流したい。
policy-routing の設定
設定の要点を Gemini に伝え、現状の netplan の設定を伝えて、policy routing の設定を提示してもらった。

---
network:
version: 2
renderer: NetworkManager
ethernets:
enp2s0:
match:
macaddress: "4C:CC:6A:F9:B0:84"
addresses: [192.168.11.3/24]
nameservers:
addresses: [192.168.11.3]
routes:
- to: default
via: 192.168.11.1
metric: 100 # メインの優先度を高く設定
enxc8a362ed15ee:
match:
macaddress: "c8:a3:62:ed:15:ee"
addresses: [192.168.1.51/24]
routes:
# メインのルーティングテーブルにはデフォルトゲートウェイを書かない
# 代わりに、Squid専用の「テーブル200」の中にだけゲートウェイを作る
- to: default
via: 192.168.1.254 # 上流ルーター
table: 200
routing-policy:
# 192.168.1.51 を「出発地」とするパケットだけをテーブル200へ飛ばす
- from: 192.168.1.51
table: 200
適用して、問題がなさそうなので、squid に以下の設定を追加。
((( /etc/squid/conf.d/policy-routing.conf ))) tcp_outgoing_address 192.168.1.51
動作を確認
Proxy ナシの Chrome と Proxy アリの Firefox を起動して、YouTube を閲覧中。catvstb でも 上流ルータをそのまま使って YouTube を視聴中。CATVSTB=赤、SquidProxy=青、通常パケット=水色でトラヒックが分散されている。自宅外からWebサーバが閲覧できることも確認できた。満足…

HTTP3+QUIC 対応で FireWall に udp/443 を追加しただけ
HTTP3+QUIC だと、QUIC 用に UDP/443 を使うらしい。
サーバの設定は後で見直すとして、ひとまず FireWall + 自宅ルータの DMZ 設定で、UDP/443 を追加してみた。
んで、apache2 で HTTP3+QUICK を探すと、標準モジュールでは対応していないとな。さすがに apache を手作業インストールで運用する気はおこらんなぁ…
arpalertをarpwatchに変更
不審なネットワーク接続を見つけるために、arpalert を使っていたけど、新しい端末を登録するときに警告メールが飛んでこない。サーバを切り替え ubuntu に変更となって、何も考えずに arpalert をインストールしてあったけど、細かい点の動作確認をしていなかった。
調べると arpalert は最近メンテナンスされていないらしい。systemctl status arpalert すると、/etc/init.d/arpalert の sysv 形式で起動している。古い証拠なので切り替え。
最近は arpwatch を進められたので、arpwatch に切り替え。
arpwatch の設定
設定は、設定対象のインタフェース名(自宅の場合 enp2s0)をしらべ、以下で起動
$ sudo apt install arpwatch $ sudo vi /etc/arpwatch/enp2s0.iface IFACE_ARGS="-m root@tsaitoh.net" # 警告メールの送り先 PCAP_FILTER="net 192.168.11.0/24" # 監視対象を制限 $ sudo systemctl enable arpwatch@enp2s0 $ sudo systemctl start arpwatch@enp2s0 $ sudo apt remove arpalert
iOS26.2とIPアドレストラッキング
iOS26.2にして、自宅サーバ限定ページが見えない。確認すると「IPアドレスのトラッキング制限」が ON になってら。
マナーの悪いクローラーの拒否
自宅サーバの Web サーバの負荷が上がってる。
CTFで公開しているブルートフォース問題へのアクセスかと思ったけど、apache2のaccess.log をみると、207.241.225.60 のアドレスからページ全体をなめまわしている。whois を実行すると、アメリカの Internet Archive なる組織。
間髪を入れないでアクセスしてくるような、マナーの悪いクローラは拒否されても仕方ないよね。
ということで、個別の アクセス拒否リストに、以下を追加する。
207.241.225.0/24 # 2025-11-21 207.241.238.0/24 # 2025-11-21
nextr 2G を活用するには
nextr 2G を活かせていない
我が家のネットワーク契約は、こしの都ネットワーク(丹南ケーブル) nextr 2G の契約だけど、自宅の端末の管理をきめ細かくしたいので nextr 2G のルータ(G-240W-B GPON) の配下に Buffalo のルータを設置。すべてのネットワーク機器は Buffalo ルータ配下に設置している。このためすべてのトラヒックは、Buffalo ルータ経由となり、ルータの WAN 側は 1G bps なので、2Gbps の最大性能の半分しか使っていない。
改善前の性能
自宅サーバで動かしたブラウザと、Windows で動かしたブラウザで、それぞれを別タイミングで動かすと以下の性能で 1Gbps に近い性能が出る。

しかし、サーバのブラウザとWindowsのブラウザで同時に計測すると、全部が Buffalo のWAN側を通るので、1Gbps の性能になってしまう。(speedtest のリロードボタンの同時押しがなかなかできないので、微妙にタイミングがずれるので500Mbpsを若干越えてるけど)

nextr 2G で WiFi と2つのLANポートに分散
そこで、nextr 2G のルータで活用していなかった WiFi と 2つのLANポート(各1Gbps)で分散を目指した。
nextr 2Gの WiFi は、CATVSTB の インターネット側を 設定。また、自宅サーバに USB 接続の 1Gbps の有線LANを追加し、未使用だった nextr 2G ルータの2つ目の LAN ポートに接続。
これで、サーバのトラヒック(max 1Gbps)と端末のトラヒック(max 1Gbps)に分散して 2Gbps を目指した。

この結果、サーバと端末で同時に speedtest を起動しても 1Gbps に近い性能がでるようになった。
とはいっても、ブラウザで動画を家族それぞれが見たとしても、3人で 100Mbps のトラヒックでさえも出ないけど。
外から自宅サーバが見えない
分散はできるようになったものの、自宅サーバ宛てのメールが届かない。確認したら、Web サーバも外から見えない。外から、Buffalo ルータ経由でアクセスできると思ってたけど。抜き差しする可能性のある USB 有線LANだし、できればnextr 2G ルータの DMZ 設定変更したくないんだけど。もう少し、設定チューニング必要だな。ひとまず USB 有線 LANを抜いておく。
原因としては、パケットが出る際の経路(サーバ⇒nextr 2Gルータ⇒インターネット)、パケットが入る際の経路(インターネット⇒nextr 2Gルータ⇒Buffaloルータ⇒サーバ)の不一致のせい。Gemini に対応案を提案してもらうと、3つの対策を提案してくれた。
- ルータのインターネット接続を Buffalo ルータ経由にする案を提案してくれるが、これじゃトラヒック分散にならない。
- nextr 2Gルータの DMZ の宛先を直接サーバ: 抜き差しする可能性のある 有線LAN だしなぁ。
- PBR(ポリシーベースルーティング)を提案してくれるが、設定は複雑化するとな。
FTTHルータの流量モニタ
以前より、丹南ケーブルへの接続用の FTTH ルータ G-240W-B GPON の munin 用の流量モニタを運用していたけど、WiFi の流量のモニタ機能を追加。これにあわせて、Packet 量でのモニタリングを Byte をモニタするように切り替えた。前も Byte 運用失敗してたけど、再チャレンジ。
でも、運用最初はそれなりに正しそうなグラフなんだけど、数時間動かすと GPON の WiFi を使っているのに流量が表示されなくなる。munin の プラグイン の使い方として、Byte だと通信量のカウンタのオーバーフローしているのかと、色々触ってみるが、改善せず。やむなく パケット単位でのモニタリングに戻す。なんでかなぁ…

光回線ルータの WiFi を稼働させる
自宅ネットワークは、丹南ケーブルの光2G 回線。光のルータの LAN ポートは 1Gbps 回線。自宅ネットワークは、IPアドレス管理をきめ細かく扱っているため、光ルータでは DHCP を切ることができず、家の中で広く WiFi を使えるようにするため、メッシュ機能のルータを設置してあり、若干効率が悪いものの2段ルータ構成となっている。メッシュのルータは WAN側が 1Gbps であり、光2Gbps を有効利用できていない。とはいえ、WiFiの電波の取り合いを避けるため 光ルータの WiFi は切っていたけど、今回 光2G を少しでも有効活用を考えた。
ということで、自宅の動画視聴に活用されている CATB-STB の動画視聴のネットワークを 光2Gルータに WiFi で接続できるように設定。
上記のネットワークモニタの画面の 赤部分が 光ルータの WiFi 回線。つまり赤が自宅TVで、Netflix や YouTube を見ていたトラヒック。水色はメッシュ WiFi ルータのトラヒック。
