かつお Back Up Guard (わんわんバックアップ) — 試験運用記録

実証済 商用化準備 遠隔地の Windows PC を暗号化トンネル経由で自社ストレージにバックアップする商用サービス。 katuocloud 既存インフラに相乗りする形で実証試験完了。 商業展開準備中。

katuocloud 既存インフラに相乗りする形で、 遠隔地の Windows PC を暗号化トンネル経由で自社ストレージにバックアップするサービスの実証試験を実施。 マンション共有 Wi-Fi / iPhone テザリング環境下で、 SSH 接続およびファイル取得まで通しで成功。 事業のコア機能の動作証明を完了。

cd /etc/wireguard
umask 077

# 鍵生成
wg genkey | tee wg-backup_private.key | wg pubkey > wg-backup_public.key
wg genkey | tee testpc_private.key | wg pubkey > testpc_public.key
wg genpsk > testpc_psk.key

# 設定ファイル作成
cat > /etc/wireguard/wg-backup.conf << 'EOF'
[Interface]
Address = 10.220.0.1/24
ListenPort = 62001
MTU = 1100
PrivateKey = (server private key)
SaveConfig = false

[Peer]
# wanwan-test-001
PublicKey = (testpc public key)
PresharedKey = (testpc psk)
AllowedIPs = 10.220.0.2/32
EOF

chmod 600 /etc/wireguard/wg-backup.conf
chmod 600 /etc/wireguard/*.key
systemctl enable --now wg-quick@wg-backup

# NAT追加 (62001 → 192.168.70.30 maguro)
nat descriptor masquerade static 20000 14 192.168.70.30 udp 62001

# フィルタ定義
ip filter 400063 pass * 192.168.70.30 udp * 62001

# tunnel インターフェースに適用 (← これが必要)
tunnel select 1
ip tunnel secure filter in 400060 400061 400062 400063 ...
tunnel select none
save

# wg-backup INPUT (順序重要)
iptables -I INPUT 1 -i wg-backup -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT 2 -i wg-backup -p icmp -j ACCEPT
iptables -I INPUT 3 -i wg-backup -p tcp --dport 22 -j ACCEPT
iptables -I INPUT 4 -i wg-backup -j DROP

# wg-backup FORWARD (本番セグメント侵入防止)
iptables -I FORWARD 1 -i wg-backup -d 10.200.0.0/16 -j DROP
iptables -I FORWARD 2 -i wg-backup -d 192.168.20.0/24 -j DROP
iptables -I FORWARD 3 -i wg-backup -d 192.168.30.0/24 -j DROP
iptables -I FORWARD 4 -i wg-backup -d 192.168.70.0/24 -j DROP

# TCPMSS clamp (MTU調整、 TCPセッション破損防止)
iptables -I FORWARD -i wg-backup -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -I FORWARD -o wg-backup -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -I OUTPUT  -o wg-backup -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# 永続化
iptables-save > /etc/iptables/rules.v4

cat > /etc/sysctl.d/99-wg-backup.conf << 'EOF'
net.ipv4.conf.wg-backup.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
EOF
sysctl -p /etc/sysctl.d/99-wg-backup.conf

# OpenSSH Server インストール
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

# Firewall 22番開放
New-NetFirewallRule -Name "OpenSSH-Server-In-TCP" `
    -DisplayName "OpenSSH Server (sshd)" `
    -Enabled True -Direction Inbound `
    -Protocol TCP -Action Allow `
    -LocalPort 22 -Profile Any

# WGプロファイル Private
Set-NetConnectionProfile -InterfaceAlias "test-laptop-001" -NetworkCategory Private

# 管理者ユーザー用 authorized_keys (administratorsグループの場合の特殊パス)
$adminKeysFile = "C:\ProgramData\ssh\administrators_authorized_keys"
Add-Content -Path $adminKeysFile -Value $pubKey
icacls.exe $adminKeysFile /inheritance:r
icacls.exe $adminKeysFile /grant "Administrators:F"
icacls.exe $adminKeysFile /grant "SYSTEM:F"
Restart-Service sshd

原因: RTX1300 のフィルタ 400063 を ip filter で定義しただけでは効かず、 tunnel select 1 経由で tunnel インターフェースに適用する必要があった。

解決: tunnel select 1 → ip tunnel secure filter in ... 400063 ... → save で恒久対処完了。

原因: サーバー側 iptables INPUT に -m state --state RELATED,ESTABLISHED -j ACCEPT ルールがなく、 SYN-ACK 応答パケットが INPUT 末尾の DROP に弾かれていた。

解決: ESTABLISHED ルールを INPUT 1 (最優先) に挿入。 これでサーバーから開始した TCP セッションの戻りパケットが正しく許可される。

原因: WG MTU デフォルト 1420 がモバイル網 CGNAT で断片化を起こす。
解決: MTU = 1100 を両端で設定。 TCPMSS clamp も併用。

原因: OpenSSH は「最初にマッチした Host 定義を採用」する仕様。 Include 行を末尾に置くと既存の Host 定義に上書きされる。
解決: Include 行を config ファイル先頭に挿入。

原因: Windows OpenSSH Server は administrators グループに属するユーザーの場合、 ~/.ssh/authorized_keys ではなく C:\ProgramData\ssh\administrators_authorized_keys を参照する仕様 (sshd_config の Match Group ブロック)。
解決: 管理者用の専用パスに登録、 icacls で権限を SYSTEM:F + Administrators:F + inheritance:r に設定。

• smbpasswd/testparm/pdbedit が samba-common-bin から消失 → apt install --reinstall samba samba-common-bin smbclient
• /usr/share/samba/is-configured 不在で systemd ExecCondition 失敗 → /etc/systemd/system/{smbd,nmbd}.service.d/override.conf で ExecCondition= を空に
• /run/samba 不在 → /etc/tmpfiles.d/samba.conf を作成
• interfaces = lo wg-backup が効かず → IP 直書きで解決

/srv/storage/                                    [64TB空き、 LUKS raid1-4 + bcache + XFS]
├── nextcloud-data/                              [Nextcloud本体データ]
└── nextcloud/backup/
    ├── daily/, weekly/, monthly/                [既存システムBK]
    └── wanwan-veeam/                            ★ わんわんバックアップ
        └── <client_id>/
            ├── Wanwan-Backup-<ID>-MonthlyImage/  [Veeam .vbk]
            │   ├── Wanwan-Backup-...vbm
            │   └── Wanwan-Backup-...vbk
            └── daily/                            [rsync 30世代]
                ├── 20260430-110252/c/...        [タイムスタンプ別]
                └── latest -> 20260430-110252    [相対symlink]

• BIOS の「高速スタートアップ」無効化
• Windows 電源プラン: スリープ解除タイマー有効、 休止状態を有効化
• タスクスケジューラ: 毎日 02:00、 「タスクの実行時にスリープを解除する」有効
• WireGuard を Windows サービスとして起動 (起動時自動接続)
• 保険タスク: PC 起動から3時間後に shutdown /h

• cron 02:05 で backup-client.sh 実行
• 顧客リスト管理 (DB or YAML)
• 顧客ごとに並列実行 / シリアル実行を選択
• 完了後 ssh shutdown /h で休止状態へ

• cwRsync 6.4.7 (Windows用 rsync 3.4.1) を rsync.exe + 必要DLL のみ抽出して配布
• サーバー → ノートPC へ rsync -av --link-dest=.. で7世代ハードリンク世代管理
• 初回フル + 以降差分で帯域大幅節約

• 既存の maguro Telegram 監視システムに統合 (cert-watch / supermicro-watch と同じ仕組み)
• 毎日のバックアップ完了/失敗を通知
• 1週間バックアップ無しの顧客をエスカレーション

• 顧客ごとに別の SSH 鍵ペアを発行 (鍵分離)
• 鍵の保管場所を専用ディレクトリに集約 + パーミッション 600
• 定期的な鍵ローテーション運用 (3〜6ヶ月)
• 鍵ファイルのバックアップ (LUKS 暗号化領域内に保管)
• maguro OS 自体のセキュリティ更新 / fail2ban / 不正ログイン検知

営業上、 顧客から「Cドライブ全体をバックアップしてほしい」「障害対応で操作してほしい」という要望は当然発生する。 SSH 接続後の操作範囲を技術的に過度に制限すると、 顧客対応の柔軟性が失われる。 サーバー側の鍵管理を厳格化することで、 サーバー側のセキュリティを担保する方針とする。

1. 顧客から復元依頼受領 → 対象顧客 ID 確認
2. DarkHero (Win11) のエクスプローラーで \\173.0.0.17\wanwan-admin をマップ済 Z: ドライブから開く
3. 顧客の daily/<timestamp>/c/ から目的ファイルを目視で特定 (Veeam GUI不要)
4. コピー → 顧客へ送付 (Nextcloud 経由 or 持参)
5. 速度実測値: 167MB ファイル取り出し 450 MB/s (3.6 Gbps)

バックアップを業者に任せるとき、 最大の懸念は「業者が悪意を持ったら全PCを乗っ取れるのでは？」という点。 この懸念を真正面から取り上げ、 実際にどれだけ簡単に乗っ取れるかを実演し、 「だからこそ信頼できる業者選びが重要」という結論で わんわんバックアップ に誘導する動画コンセプト。

• YouTube 向けに 10〜15分の解説動画
• X (Twitter) でハイライト30秒切り抜き
• かつおくん / わんくん のゆっくり解説スタイル援用
• 動画内で maguro 側鍵管理の厳格性をアピール