インフラ on 怠惰技術ブログ

Raspberry Pi 2台構成のWiFi APでSSIDが起動時に出ない問題を解決した

Wed, 06 May 2026 18:00:00 +0900

Raspberry Pi 2台でESS構成（同一SSID・別チャンネル）のWiFi APを組んだところ、OS起動時にSSIDが出ない問題が発生。NetworkManagerとhostapdの起動順序が原因だったのでsystemdのoverride.confで解決した。

自宅NWをKeepalivedとdnsmasqで作り直した話

Sat, 18 Apr 2026 19:00:00 +0900

背景

自宅のネットワーク構成が辛かった。

具体的には以下の問題があった。

ルータが1台構成で、死んだら自宅NW全滅
メンテナンスで定期的に落としたいとかあっても、コストが大きい
DNS/DHCPがルータに同居していて、役割が混在している
WireGuardで外部接続していたが、外部からの入り方がだるい。

特に「冗長化したい」という気持ちは何年も前からあったが、DNSとDHCPの同期という難問の前に何度も挫折してきた。

結論からいえば、DNS,DHCPの冗長化は諦めた。

諦めた上で出口のルータとDNS、DHCPは役割を分けた上で出口のルータとWIFIルータのみ冗長化を実施した。

設計方針

過去の失敗から学んだ一番の教訓はやはり「DNS/DHCPの冗長化は難しい」ということだ。

理論上可能ではあるが、私は万年初級自宅インフラエンジニアでいつまで経ってもできる目処が立たない。

それでいて、生成AIという過ぎた兵器を持ってしても、この問題は解決しなかったので、難しいというよりは不可能とした。

2台のサーバでDHCPを冗長化しようとすると、リースの同期問題が必ず発生する。同期ツールを使ったりしたが、どうしても同期しきれなかった。

そこで今回は思い切って諦めた上で役割を分離する方針にした。

ルータ（冗長化） → GWとTailscaleだけ担当
AP             → hostapdのみ
DNS/DHCP       → 専用機1台に集約（冗長化しない）

DNSとDHCPは単一障害点になるが、自宅ラボであれば許容範囲だと判断した。

てかどうしようもない。

構成

使用機材はすべてRaspberry Pi。封印していたタワーからも引っ張り出した。

ホスト	役割
ルータA (MASTER)	Keepalived + Tailscale
ルータB (BACKUP)	Keepalived + Tailscale
DNS/DHCP機	dnsmasq専用
AP x2	WIFI冗長化

ネットワークセグメントはひとつ。VIPをデフォルトゲートウェイ兼DNSとして各クライアントに配布する。

Keepalivedの設定

まずルータ2台にKeepalivedを入れる。

sudo apt install -y keepalived

MASTER側の設定:

vrrp_instance VI_1 {
    state MASTER
    interface lan-if
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass xxxxxxxx
    }
    virtual_ipaddress {
        192.168.xx.1/24
    }
}

BACKUP側は state BACKUP と priority 90 に変えるだけ。シンプルだ。

ドメイン購入後のやり残し作業 - メールとDNS設定編

Tue, 14 Apr 2026 22:00:00 +0900

wasutech.dev を公開したはいいが、メール周りを何もしていなかった。放置するとなりすましに悪用される可能性があるので、Cloudflare Email Routing・SPF・DMARCを設定した。

Cloudflare Email Routing

自前のメールサーバーを建てるのはコストがかかる。Cloudflareには Email Routing という機能があり、@wasutech.dev 宛のメールを既存のGmailなどに転送できる。無料。

仕組みとしては、Cloudflareが自動でMXレコードを追加し、受信したメールを指定のアドレスへ転送する。

dig MX wasutech.dev
# → isaac.mx.cloudflare.net 等が返ってくる

MXレコードはドメインレベルの情報なので、転送先のメールアドレスは外部に公開されない。dig で見えるのはCloudflareのサーバーだけで、「どこに転送しているか」は誰にもわからない。

設定はCloudflareのダッシュボードから数クリックで完了する。

転送先のアクションは3種類から選べる。

アクション	動作
Forward to email	指定のメールアドレスへ転送
Drop	受信して即破棄。転送しない
Send to Worker	Cloudflare Workersで独自処理

今回はメールを受け取る必要がないため Drop に設定した。スパム対策にもなるし、転送先アドレスを管理する必要もない。Workers連携は受信メールをSlackに流したり、自動返信を実装したりする場合に使う。

SPF - 送信元を証明するレコード

SPFとは

SPF（Sender Policy Framework） は、「このドメインからメールを送信していいサーバーはどこか」を定義するDNSレコード。

なぜ必要か。メールのプロトコル（SMTP）は設計上、送信元アドレスを自由に詐称できる。つまり誰でも admin@wasutech.dev を名乗ってメールを送れる。SPFはこれを受信側が検証できるようにする仕組み。

受信側のメールサーバーは、届いたメールの送信元IPアドレスを確認し、そのドメインのSPFレコードに記載されたIPと照合する。一致しなければ怪しいメールとして処理できる。

設定したレコード

v=spf1 include:_spf.mx.cloudflare.net ~all

各要素の意味：

要素	意味
`v=spf1`	SPFバージョン1
`include:_spf.mx.cloudflare.net`	CloudflareのメールサーバーからのSMTPを許可
`~all`	上記以外は「疑わしい」扱い（ソフトフェイル）

~all は疑わしいメールを迷惑メール扱いにする。-all にすると完全拒否になるが、DMARCと組み合わせて制御するのが一般的。

確認：

dig TXT wasutech.dev
# v=spf1 include:_spf.mx.cloudflare.net ~all

DMARC - SPFの結果を使って何をするか決めるレコード

DMARCとは

DMARC（Domain-based Message Authentication, Reporting, and Conformance） は、SPF（やDKIM）の検証結果に基づいて、受信側が「そのメールをどう扱うか」を指示するレコード。

Cloudflareの全通知をDiscord Webhookに飛ばす

Sun, 12 Apr 2026 18:00:00 +0900

CloudflareのNotificationsはUIから1個ずつ設定するのがとにかくだるい。種別も多いし、手動でDiscord Webhookを登録していくのは非現実的。

Cloudflare APIとWorkersを組み合わせて全通知を一括登録する。

構成

Cloudflare Notifications
        ↓
  Cloudflare Worker (受け口)
        ↓
  Discord Webhook

Cloudflare NotificationsはWebhook送信に対応しているので、Workerを受け口にしてDiscordに転送する。

1. Discord Webhookを作成

通知を飛ばしたいDiscordチャンネルの設定から作成する。

チャンネル設定 → Integrations → Webhooks → New Webhook → Copy Webhook URL

2. Cloudflare Workerを作成

Cloudflareダッシュボードから Workers & Pages → Create → Hello World で作成する。

名前は cf-notify-discord など適当につけてDeploy。

エディタ画面で以下のコードに置き換える。

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("ok");
    }

    let body;
    try {
      body = await request.json();
    } catch {
      return new Response("invalid json", { status: 400 });
    }

    const message = {
      username: "Cloudflare",
      embeds: [{
        title: body.text?.title || "Cloudflare Notification",
        description: body.text?.description || JSON.stringify(body, null, 2),
        color: 0xF6821F,
        timestamp: new Date().toISOString()
      }]
    };

    await fetch(env.DISCORD_WEBHOOK, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(message)
    });

    return new Response("ok");
  }
}

Discord WebhookのURLはWorkerのSettings → Variables and Secretsでシークレットとして登録する。

歴史地図アプリを雑にk3sへデプロイした

Wed, 25 Feb 2026 22:00:00 +0900

React+Vite+MapLibreで作った歴史地図アプリをk3sにデプロイした話。hostPathマウント、Viteの罠、ngrokとTailscaleを駆使したファイル転送など泥臭い記録。