katuocloud既存インフラに相乗りする形で、遠隔地のWindows PCを暗号化トンネル経由でR640にバックアップするサービスの実証試験を実施した。マンション共有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]
# test-laptop-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.20.21)
nat descriptor masquerade static 20000 14 192.168.20.21 udp 62001

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

# tunnel インターフェースに適用 (← これが必要)
tunnel select 1
ip tunnel secure filter in 400060 400061 400062 400063 400214 400210 400211 400003 400020 400021 400022 400023 400024 400025 400030 400032
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 10.250.0.0/24 -j DROP
iptables -I FORWARD 3 -i wg-backup -d 10.251.0.0/24 -j DROP
iptables -I FORWARD 4 -i wg-backup -d 192.168.20.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

# /root/.ssh/config の先頭に Include を配置 (重要)
sed -i '1i Include /root/.ssh/config.d-wanwan-backup\n' /root/.ssh/config

# /root/.ssh/config.d-wanwan-backup
Host wanwan-test-001
    HostName 10.220.0.2
    User wan6
    Port 22
    IdentityFile /root/.ssh/backup-keys/wanwan-backup
    IdentitiesOnly yes
    PasswordAuthentication no
    StrictHostKeyChecking accept-new
    ServerAliveInterval 30
    ServerAliveCountMax 3

# /opt/wanwan-backup/backup-client.sh
# scp でクライアントPCのファイルを R640 に取得、7世代管理

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

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

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

解決: ESTABLISHED ルールを INPUT 1 (最優先) に挿入。これでR640から開始した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 に設定。

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

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

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

• 既存の R640 Telegram監視システムに統合
• 毎日のバックアップ完了/失敗を通知
• 1週間バックアップ無しの顧客をエスカレーション

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

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

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

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

• katuocloud本体: wg0 (port 54024) / Nextcloud Docker / FastAPI portal
• VPS連携: wg2 (port 60050) / Xserver VPS 162.43.8.20
• ドメイン使い分け: katuocloud.com (販売LP) / k2-o.net (技術ドメイン、契約者のみ) / wan-secure.net (Collabora alias)
• 監視基盤: Telegram通知システム流用
• ストレージ: /backup ディレクトリ、容量に応じてSupermicro NFS連携

© 2026 みーきゅんわんわん / katuocloud
試験実施日: 2026年4月29日 / Document version: 1.0