VRSCを現在の設置拠点に置いたまま、インターネット越しの別拠点にあるDG-PRO1RWSへRTK補正を提供する。既存のXserver VPSとRaspberry Pi WireGuardゲートウェイを再利用し、VRSCの認証なしNTRIPポートを一般公開しない構成を目指す。
本書はIssue #20の子Track #22で比較し、Track #23で常設化した構成を記録する。2026-07-17時点でVPSからVRSCまでのTCP経路とVRSC電源OFF/ON後の無手動復旧を確認済みである。Android/DG-PRO1RWSのアプリケーション層統合は未検証である。
2026-07-16に次を実機確認した。
| 機器 | 接続・アドレス | 確認結果 |
|---|---|---|
| VRSC | Wi-Fi AP、192.168.4.1 |
Ubuntu PCからping成功 |
| VRSC NTRIP | TCP 192.168.4.1:2101、mountpoint VRSC |
TCP接続成功 |
| Ubuntu PC Wi-Fi | 192.168.4.2/24 |
SSID VRSCへ接続済み |
| Ubuntu PC LAN | 192.168.68.134/24 |
有線LAN接続を維持 |
詳細はUbuntu PCからVRSCへWi-Fi接続するを参照する。
~/develop/vpsのIssue #1とdocs/wireguard-setup.mdには次の構成が記録されている。
| 機器 | アドレス・設定 | 記録済み結果 |
|---|---|---|
| Xserver VPS | WireGuard 10.0.0.1/24 |
Raspberry Piと疎通済み |
| Raspberry Pi 3B+ | WireGuard 10.0.0.2/24、LAN 192.168.68.130 |
VPSと疎通・再起動後自動復旧済み |
| VPSのPi peer | AllowedIPs = 10.0.0.2/32, 192.168.68.0/24 |
VPSからLANへ経路を持つ設計 |
| Raspberry Pi | IPv4 forwarding有効 | LANゲートウェイとして構築済み |
VPSからUbuntu PC 192.168.68.134への疎通と、192.168.68.134:22101からVRSCへ向かうTCP中継を確認済みである。
VRSCの通常用途では、DG-PRO1RWSがVRSCのWi-Fi APへ接続し、192.168.4.1:2101/VRSCをNTRIP clientとして利用する。
この接続は一方向のRTCM配信ではない。公式テクニカルガイドでは移動局からVRSCへ次を送る必要がある。
RXM-SFRBXNAV-PVTVRSCから移動局へは生成したRTCMを返す。このため、遠隔化ではNTRIPのTCPセッションを双方向に透過中継する必要がある。
既存WireGuardをVPS―設置拠点間の閉域経路として再利用し、Ubuntu PCでLAN側のTCP待受をVRSCへ中継する。
遠隔拠点
DG-PRO1RWS
│ Wi-FiまたはBluetooth（方式は未確定）
遠隔PC／Android
│ WireGuard peerまたは安全な中継
▼
Xserver VPS
WireGuard: 10.0.0.1
│
│ 既存WireGuard
▼
Raspberry Pi 3B+
WireGuard: 10.0.0.2
LAN: 192.168.68.130
│
│ LAN 192.168.68.0/24
▼
Ubuntu PC
LAN: 192.168.68.134
Wi-Fi: 192.168.4.2
TCP relay: 192.168.68.134:22101 → 192.168.4.1:2101
│
│ VRSC Wi-Fi
▼
VRSC
NTRIP: 192.168.4.1:2101/VRSC
TCP relayはsocatをsystemdで常設し、NTRIP内容を解釈・変換せず、クライアントごとのTCPストリームを双方向に転送する。LAN限定で待ち受け、VRSCの認証なしポートを一般公開しない。
遠隔側DG-PRO1RWSの現在の接続方法が未確認のため、次の候補を残す。
遠隔PCをVPSの新しいWireGuard peerとして追加し、VPN内アドレスで中継先へ接続する。
AndroidのWireGuard VPNからVPSへ入り、Drogger-GPSで「レシーバーのNtripを使う」をOFFにしてAndroid側NTRIP clientを使う候補。
DG-PRO1RWSまたは遠隔端末がVPSの公開アドレスへ直接接続する案。
VRSCの初期NTRIP設定はユーザー名・パスワードなしである。単純なポート転送では第三者から接続可能になるため、現時点では採用しない。固定接続元IP制限や認証付きフロントエンドを別途設計できた場合のみ再検討する。
192.168.68.134へ疎通する。合格条件は、VPSからUbuntu PCへ安定して到達でき、既存サービスへ影響がないこと。
192.168.4.1:2101に固定する。合格条件は、バイト列を変更せず双方向転送でき、異常終了後に再接続できること。
合格条件は、公開ネットワークへ待受を露出せず、VPSからVRSCまで双方向TCPが継続すること。
VRSC mountpointへ接続する。RXM-SFRBX/NAV-PVT、下りRTCM、Ntrip Statusを確認する。合格条件は、ローカル直結時と遠隔時を比較でき、遠隔側でFIX/FLOAT/単独測位を誤認せず記録できること。
Piのip_forwardとwg0自動接続、Ubuntu TCP relayのsystemd化を実施した。Pi再起動とVRSC電源OFF/ON後の復旧は確認済み。Ubuntu本体の再起動試験だけは未実施である。
192.168.4.1:2101をNATやポート転送で直接インターネット公開しない。0.0.0.0ではなく、必要なLANアドレスに限定して待ち受ける。| 症状 | 主な確認点 |
|---|---|
| VPSからUbuntuへ届かない | WireGuard handshake、AllowedIPs、Pi forwarding、LAN IP |
| UbuntuからVRSCへ届かない | Wi-Fi接続、192.168.4.2/24、VRSC電源、TCP 2101 |
| TCP接続するがRTCMが来ない | 上りRXM-SFRBX/NAV-PVT、mountpoint、VRSCのL6受信状態 |
| RTCMは来るがFIXしない | DG-PRO1RWS設定、衛星受信、遅延、補正データ鮮度 |
| 切断後に復旧しない | 各proxyのsocket close、NTRIP clientの再接続、WireGuard handshake |
| インターネットが使えない | デフォルトルート、Wi-Fi/LAN metric、遠隔端末のVPN route |
~/develop/vps/docs/wireguard-setup.md