接続確認用PC（192.168.68.134）で稼働しているArduSimple simpleRTK2B基準局を、専用のRaspberry Pi Zero WHへ移行し、Droggerから安定して常時利用できる構成にします。Issue #33の作業記録です。
本文書は作業途中の記録です。着手前の道筋として作成しており、実施のたびに「現時点の状況」を更新します。
192.168.68.134 上のstr2strから192.168.68.134:2101/RTK2B_BASEとしてRTCM3を配信できることを確認済み（詳細はardusimple-simplertk2b-base-setup.md）。vpsgateway、192.168.68.130）を経由し、Drogger GPSでNtrip Running、DG-PRO1RWSで3D DGNSS FLOATを確認済み（詳細はandroid-rtk-base-wireguard-connect.md）。ただしこの記録は旧構成（別体のvpsgateway Piがmasqueradeして中継する方式）であり、本文書の新構成とは異なります。192.168.68.134)は接続確認用であり、基準局として常設しない。LANアドレスもDHCP割り当てのため変更されうる。vpsgateway）とは別個体。基準局用Pi Zero WH自身をVPSのWireGuard peerとして登録し、LAN側DHCPアドレスを経由せず、WireGuard内の固定アドレスへDroggerから直接NTRIP接続します。
Droggerタブレット
WireGuard: 10.0.0.3
|
v
VPS
WireGuard: 10.0.0.1
|
v
基準局 Raspberry Pi Zero WH
WireGuard: 10.0.0.4/32（候補。割り当て前に未使用確認）
NTRIP: 10.0.0.4:2101/RTK2B_BASE
|
| USB
v
simpleRTK2B
既存のWireGuard中継用Raspberry Pi 10.0.0.2（vpsgateway）は別用途として残し、基準局のNTRIP通信では経由しません。
10.0.0.4は候補であり、割り当て前にVPS側で未使用であることを確認する必要があります。vps-gateway-access.mdと同じ方針（専用ユーザー・鍵認証のみ・最小限sudo）で揃えます。
| 項目 | 値 |
|---|---|
| ホスト名 | drogger-rtk-base |
| 作業専用ユーザー | droggerrtkbase |
| このPCの秘密鍵パス | ~/.ssh/id_ed25519_rtkbase（Ubuntu PC 192.168.68.134 にて2026-07-29生成、パスフレーズなし） |
| 公開鍵 | ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGHFyoWuOCJGIdzfXfqDlbIcoAbj8FGYZFHp5GOl6v2/ droggerrtkbase@drogger-rtk-base |
| PC2025の秘密鍵パス | ~/.ssh/id_ed25519_rtkbase_pc2025（PC2025 192.168.68.122 にて2026-08-01生成、PC2025内のみ保持） |
| PC2025の公開鍵 | ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEhrtB+7HoVPvKCoKIXFfKYegJs1gJD0QCQGn/I2HrDC droggerrtkbase@PC2025 |
最初にもう一台のPCで生成した鍵ペア（公開鍵 ...pPr4c8iR42t7i4DmmNC9NQ/ECT2unJR...）は、その秘密鍵がUbuntu PC側になく手元で認証できなかったため破棄した。Ubuntu PC上で鍵ペアを再生成し、SDカードのrootfsパーティションを直接マウントして/home/droggerrtkbase/.ssh/authorized_keysを新しい公開鍵へ書き換えることで対応した（後述のとおりSDカード全体の再書き込みは不要だった）。
2026-08-01、Track #36の基準局停止・復旧試験をPC2025から実施しようとした際、PC2025の~/.ssh/id_ed25519_rtkbaseがこの破棄済みの旧鍵と一致しておりPermission denied (publickey)になることが判明した。PC2025専用の新しい鍵ペアを生成し、Ubuntu PC 192.168.68.134（現在の正しい鍵を保持）からPiへSSH接続してPC2025の公開鍵をdroggerrtkbase@10.0.0.4の~/.ssh/authorized_keysへ追記した（134用の既存エントリはそのまま維持）。追記後、Piのauthorized_keysは134用・PC2025用の2エントリになったことを確認済み。
接続コマンド:
ssh -i ~/.ssh/id_ed25519_rtkbase droggerrtkbase@drogger-rtk-base.local
本番場所へ移設後は、LAN側DHCPアドレスやmDNSへ依存せず、VPSを踏み台にWireGuard固定アドレスへ接続します。
ssh -o ProxyJump=keinafarm \
-i ~/.ssh/id_ed25519_rtkbase \
droggerrtkbase@10.0.0.4
2026-07-30に、このPCからVPSを経由して10.0.0.4へSSH接続し、Piのホスト名、wg0=10.0.0.4/32、WireGuard・NTRIP service、TCP 2101待受を確認しました。初回接続時はPiの10.0.0.4に対するSSHホスト鍵を確認して登録します。
秘密鍵の内容は画面、チャット、Issue、ログへ表示しない。AIエージェントへ渡すのは鍵ファイルのパスだけとする（vps-gateway-access.mdと同じ規則）。
rpi-imager（1.8.5+noembed-0ubuntu5）は、「OS Customization」ダイアログでホスト名・SSH公開鍵・Wi-Fi・ロケールを設定してもSDカードへ反映されない（GUIの確認ダイアログではいを選んでも、生成されるべきfirstrun.shとcmdline.txtのsystemd.run=トリガーがどちらも書き込まれない）。ターミナルからrpi-imagerを起動すると、正しいfirstuse.shスクリプトの中身とCloudinit設定はログに出力される（つまり内部生成自体は正常）にもかかわらず、SDカードへの実際の書き込みステップが欠落していた。原因はUbuntu側パッケージング（+noembedビルド）の不具合と推測される。firstuse.shの内容をそのまま/boot（Ubuntu上でのマウント先は/media/<user>/bootfs）へfirstrun.shとして手動配置し、cmdline.txtの末尾に systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.targetを手動追記することで、GUIのバグを回避してカスタマイズを適用できた。FAT32はUnixパーミッションビットを正しく保持しないためchmod +xは見た目上効かないが、Raspberry Pi実機側の起動時マウントオプションで実行権限が付与されるため問題にならない（実際にこの方法で起動・Wi-Fi接続・SSH起動まで成功した）。/home/droggerrtkbase/.ssh/authorized_keysを、このPCで新規生成した鍵ペアの公開鍵へ直接書き換えるだけで解決した。ssh -i ~/.ssh/id_ed25519_rtkbase droggerrtkbase@drogger-rtk-base.localで接続確認済み。ホスト名drogger-rtk-base、タイムゾーンAsia/Tokyo (JST, +0900)を確認。System clock synchronizedは起動直後はnoだったが、NTPサービスはactiveなので時間経過で同期される見込み。USB（OTG）ポートはmicro-USBのため、必要な構成は次の通り: Pi Zero WH [USBポート] → micro-USB OTGアダプタ(オス)→USB-A(メス) → 既存の「USB-A to USB-C」ケーブル → simpleRTK2B [USB-Cポート]。新規に必要なのは「micro-USB OTGアダプタ（USB-Aメス変換）」のみで、USB-Cケーブル自体は既存のものを流用できる。PWR IN向け、micro-USB、5V）は別途購入・入手済み。POWER+XBEE側へ接続し、0403:6015 FTDI FT230Xとして認識された。このポートはXBeeソケット側UARTへのアクセス・給電用で、ZED-F9P本体のGNSSデータは取得できない。ケーブルをPOWER+GPS側へ差し替え、1546:01a9 U-Blox AG u-blox GNSS receiverとして認識されることを確認した。vcgencmd get_throttledはthrottled=0x0で、低電圧・スロットリングの現在値および履歴はなかった。device descriptor read/64, error -71が複数回発生している。低電圧履歴はないため、コネクタ接触・信号品質の問題と判断した。ソフトウェアによるUSB controller resetを本番対策にはしない。/dev/serial/by-id/...で固定参照できることを確認する。完了（2026-07-30）
/dev/ttyACM0、固定参照パスは/dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00。root:dialoutで、作業ユーザーdroggerrtkbaseはdialoutグループ所属済み。str2strを導入し、RTCM3 1005/1074/1084/1094/1230をRTK2B_BASEとして配信する。完了（2026-07-30）
rtklib 2.4.3.b34+dfsg-1+b1を、sudoを使わず~/opt/rtklibへ展開した。その後、常設化時に同じパッケージをaptで正式インストールし、現在は/usr/bin/str2strを使用する。/dev/を補うため、固定パスはserial://serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00:115200と指定する。serial:///dev/...では起動に失敗する。/usr/bin/str2str \
-in serial://serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00:115200 \
-out ntripc://:2101/RTK2B_BASE
127.0.0.1:2101/RTK2B_BASEへNTRIP接続し、ICY 200 OKと連続するRTCM3フレームを確認した。USB直読みでは設定対象の1074/1084/1094を確認済み。1005/1230を含む全メッセージの継続確認は、systemd常設化後のNTRIPクライアント検証でも再確認する。10.0.0.4/32を割り当てる。完了（2026-07-30）
wireguard-tools 1.0.20210914-3をsudoなしで~/opt/wireguard-toolsへ展開し、2026-07-30に鍵ペアを生成した。~/.config/wireguard/privatekey（mode 600）だけに保存し、内容を画面・チャット・Issue・ログへ表示しない。1S9jb8ynDLTayQiihgprkikJtk5O2HlDjfAySDDyYEQ=。10.0.0.2/32, 192.168.68.0/24と10.0.0.3/32であることを管理者がsudo wg show wg0 allowed-ipsで確認した。10.0.0.4/32は未使用のため、基準局Piの固定VPNアドレスとして採用する。wg-quick@wg0（enabled / active）で、永続設定はroot専用の/etc/wireguard/wg0.conf。VPS公開鍵の取得とpeer登録には管理者sudoが必要。PersistentKeepalive = 25を設定する。完了（2026-07-30）
wHlzMeXPJMRnx1h2PfzSkRUBa8TsM7Db8t4ihcFcW2w=、Endpointは162.43.33.56:51820。/etc/wireguard/wg0.conf.bak-20260730へ変更前バックアップを作成し、Pi公開鍵とAllowedIPs = 10.0.0.4/32を永続設定・実行中設定の両方へ追加した。wireguard-toolsを正式インストールし、/etc/wireguard/wg0.confをmode 600で作成。Address = 10.0.0.4/32、VPS peerのAllowedIPs = 10.0.0.0/24、PersistentKeepalive = 25を設定した。wg-quick@wg0はenabled / active。PiからVPS 10.0.0.1へのpingは3/3成功、packet loss 0%、RTT 28.4〜38.6ms。/32を追加する。192.168.68.134)宛て一時規則を撤去する。
10.0.0.3/32からPi 10.0.0.4/32のTCP 2101と戻り通信を許可する一時規則は追加済み。str2strとWireGuardをsystemdで自動起動し、障害時に復旧できるようにする。Pi再起動・USB抜き差しとも合格（2026-07-30）
rtklib 2.4.3.b34+dfsg-1+b1をaptで正式インストールし、/usr/bin/str2strを使用する。drogger-rtk-base.serviceを作成し、enabled / active (running)、0.0.0.0:2101のLISTENを確認した。unitの正本はdeploy/systemd/drogger-rtk-base.service。10.0.0.4:2101/RTK2B_BASEへ接続し、ICY 200 OKとRTCM3継続受信を確認した。ExecStartPreで固定USBデバイスの存在を確認し、異常終了時はRestart=always・RestartSec=5で復旧を試行する。str2strが古いTTYを保持したまま終了せず0 bpsになり、Restart=alwaysが発動しないことを確認した。BindsToし、deploy/udev/99-drogger-rtk-base.rulesからu-blox再接続時にserviceを起動する構成へ変更した。ICY 200 OKとRTCM3実受信までPi再起動なしで復旧した。wg-quick@wg0もenabled / active。実際の再起動後自動復旧とUSB抜き差し後の復旧は完了条件として別途実施する。192.168.68.134)へ持ち込み、Linux版Raspberry Pi Imagerで書き込んだ。当初はOS Customizationの内容がSDカードへ反映されない不具合に遭遇したが、firstrun.shとcmdline.txtのトリガーを手動配置することで回避し、ホスト名drogger-rtk-base・Wi-Fi・タイムゾーンAsia/Tokyoが適用された状態での起動・SSH接続を確認した。SSH鍵は別PCで生成した鍵の秘密鍵がこのPCになかったため、Ubuntu PC上で鍵を再生成し、SDカードのrootfs上のauthorized_keysを直接書き換えて対応した。詳細な不具合内容・回避策は上の手順1に記載。POWER+GPSポートでu-bloxとしての認識、接続状態での起動、低電圧履歴なしを確認した。USB未接続起動後の接続でDWC OTG列挙エラーを1回再現したが、自家用常設設備のため反復抜き差しと根拠のない部材交換は行わない。抜け止めを施し、USBを外した場合は接続後のPi再起動を復旧手順とする。/dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00を確認した。RTK2B_BASEへ接続してICY 200 OKとRTCM3継続受信を確認した。10.0.0.4/32を割り当てた。wg-quick@wg0のenabled / active、PiからVPSへの疎通を確認した。str2strが0 bpsのまま残る不具合は、device unitへのBindsToとudev起動要求で修正し、USB切断時の自動停止と再接続時のNTRIP/RTCM自動復旧に合格した。この作業はAndroidタブレット実機が必要なため、2026-07-30のPi/VPS作業セッションでは未実施。既存経路を失わないよう、Pi経路の動作確認が終わるまでは旧PC向け設定を削除しない。
AndroidタブレットでWireGuardアプリを開く。
使用中のトンネルDrogger-VRSCの編集画面（鉛筆アイコン）を開く。
Peer欄の「許可するIPアドレス」へ10.0.0.4/32を追加する。既存の192.168.4.1/32と192.168.68.134/32は、この時点では削除しない。
変更例:
変更前: 192.168.4.1/32, 192.168.68.134/32
変更後: 192.168.4.1/32, 192.168.68.134/32, 10.0.0.4/32
設定を保存し、トンネルを一度OFFからONへ切り替える。
可能ならAndroid側で10.0.0.4への経路がWireGuardトンネルへ入ったことを確認する。
| 項目 | 設定値 |
|---|---|
| 接続名 | RTK2B_BASE |
| Ntrip Casterタイプ | その他 |
| ホスト | 10.0.0.4 |
| ポート | 2101 |
| マウントポイント | RTK2B_BASE |
| ユーザー名・パスワード | なし |
| GGA送信 | なし |
Drogger-VRSCをONにする。Running。10.0.0.4:2101/RTK2B_BASE。1005、1074、1084、1094、1230の受信周期が継続更新される。FLOAT以上へ遷移する。192.168.68.134を停止しても接続が継続する。新Pi経路の成功を確認してから、VPSのDOCKER-USER chainを整理する。
sudo iptables -S DOCKER-USERとpacket/byte counterを確認する。
Pi向け戻り規則の重複1件を削除し、新Pi向け規則を往路・戻り各1件だけにする。
旧PC 192.168.68.134向けの往路・戻り規則（現状は各2件）をすべて削除する。
最終的に次の2規則だけが基準局用として残ることを確認する。
-s 10.0.0.3/32 -d 10.0.0.4/32 -i wg0 -o wg0 -p tcp --dport 2101 -j ACCEPT
-s 10.0.0.4/32 -d 10.0.0.3/32 -i wg0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
VPSの既存ファイアウォール永続化方式を確認し、上記2規則がVPS再起動・Docker再起動後にも復元されるようにする。管理方式を確認せずiptables-persistentや独自unitを追加しない。
Android WireGuardのAllowed IPsから、不要になった旧PCの192.168.68.134/32だけを削除する。既存VRSC用192.168.4.1/32と新Pi用10.0.0.4/32は残す。
10.0.0.4/32を削除し、Drogger GPSのNTRIPホストを旧PC 192.168.68.134へ戻す。sudo systemctl disable --now drogger-rtk-base.service。再開はsudo systemctl enable --now drogger-rtk-base.service。sudo systemctl disable --now wg-quick@wg0。再開はsudo systemctl enable --now wg-quick@wg0。sudo wg set wg0 peer 1S9jb8ynDLTayQiihgprkikJtk5O2HlDjfAySDDyYEQ= remove。永続設定は変更前バックアップ/etc/wireguard/wg0.conf.bak-20260730を参照してPiの[Peer]ブロックだけを戻す。Windows PC（Raspberry Pi Imager経由、カードリーダーはNORELSYS 1081CS0/CS1のUSBリーダー）で発生した事象と切り分け結果を時系列で記録する。
The disk may be write-protected or in use by another application. というメッセージ。Get-MpPreferenceを実行するとエラー0x800106ba。ウイルスバスターがメイン保護のためWindows Defenderサービス自体が停止しており、この機能はそもそも動作していない → 原因ではないdiskpartで対象ディスク（ディスク2、14GB、SDカード）のattributes diskを確認: 現在の読み取り専用状態: いいえ、読み取り専用: いいえ → 書き込み保護フラグは立っていないdiskpartセッション自体がディスクを選択(select disk)した状態で排他ロックを保持していた可能性を疑い、exitで終了してから再試行 → 変化なしdiskmgmt.msc）でディスク2を確認: 14.84GB、FAT32、状態は「正常（プライマリパーティション）」で健全。書き込み失敗のたびにドライブ文字が解除される現象を確認したが、これはRaspberry Pi Imagerが生ディスクへ排他アクセスするために書き込み前にボリュームをアンマウントする正常な仕様と判断（手動でドライブ文字を再割り当てすれば都度復旧する）Issue #33を正本とします。
str2strが自動復旧する。RTK2B_BASEへ接続できる。RunningとRTCM3継続受信を確認する。FLOAT以上へ遷移する。192.168.68.134を停止しても基準局サービスが成立する。