Issue #20の子Track #22で、既存WireGuard経路とUbuntu PCを使ってVPSからVRSCまでの双方向TCP経路を確立するための実行前手順書である。
本書は未検証の計画である。記載順に実機確認し、結果・差分・復旧方法を反映してからdocs/procedures/の再利用手順へ昇格する。
この手順では次を行わない。
構成全体と候補比較はVRSC遠隔NTRIP中継 構成案を参照する。
Raspberry Piへの検証済みSSH接続と限定sudoはVPS WireGuardゲートウェイPiへの作業アクセスを使用する。
VPSから既存WireGuardとRaspberry Piまでの経路を再確認し、今回のUbuntu PC 192.168.68.134へ到達するための往復経路またはNAT方式を特定する。Ubuntuへのpingは予備確認とし、到達性の最終判定はPhase 3のTCP接続で行う。
合格条件:
Ubuntu PCでLAN側TCP待受を作り、VRSC 192.168.4.1:2101へ透過中継する。
合格条件:
VPSからWireGuard経由でUbuntuの一時TCP proxyへ接続する。
合格条件:
192.168.4.1:2101へ接続できる| 機器 | インターフェース | アドレス |
|---|---|---|
| VPS | WireGuard | 10.0.0.1/24 |
| Raspberry Pi | WireGuard | 10.0.0.2/24 |
| Raspberry Pi | LAN（wlan0、2026-07-17実測で判明。旧記録は192.168.68.141/eth0） |
192.168.68.130/24 |
| Ubuntu PC | LAN enp2s0 |
192.168.68.134/24 |
| Ubuntu PC | VRSC Wi-Fi wlx90de80ecd0ce |
192.168.4.2/24 |
| VRSC | Wi-Fi AP/NTRIP | 192.168.4.1:2101 |
一時proxyの候補ポートは22101/tcpとする。実行時に既存利用がないことを確認し、競合時は別ポートを選ぶ。
実行前に次を記録する。
秘密鍵、パスワード、Wi-FiパスワードはIssue、ログ、ドキュメントへ記載しない。
VPSとRaspberry Piで次を保存または作業ログへ転記する。秘密鍵を含むwg0.conf本文は記録しない。
date --iso-8601=seconds
hostname
ip -brief address
ip route
sudo wg show
sudo sysctl net.ipv4.ip_forward
sudo nft list ruleset
sudo iptables-save
Ubuntu PCでは次を確認する。
date --iso-8601=seconds
hostname
ip -brief address
ip route
nmcli -f DEVICE,TYPE,STATE,CONNECTION device status
ss -lnt
sudo ufw status verbose
sudo nft list ruleset
sudo iptables-save
ip route get 192.168.4.1
ip route get 10.0.0.1
ip route get 192.168.4.1がVRSC用Wi-Fiを使い、通常のdefault routeが有線LANを優先していることを確認する。
VPSで実行する。
sudo wg show
ping -c 3 -W 2 10.0.0.2
ping -c 3 -W 2 192.168.68.141
ip route get 192.168.68.141
次を記録する。
192.168.68.141がwg0へルーティングされることここで失敗した場合は先へ進まず、WireGuardサービス、VPSのパケットフィルター、Raspberry Piのインターネット接続を確認する。
VPSで実行する。
ping -c 3 -W 2 192.168.68.134
pingが許可されていない可能性を区別するため、Ubuntuで既存待受ポートを勝手に公開して代用しない。Phase 2の一時proxyを開始した後、TCP接続で最終判断する。
pingに失敗しても、それだけではPhase 1失敗とせずPhase 2へ進めてよい。ただし、5.1のVPS―Raspberry Pi疎通と5.3の戻り経路/NAT方式の説明が成立していることを前提とする。VPSからUbuntu PCへ到達できるかは、Phase 3で一時proxyへのTCP接続結果をもって確定する。
Ubuntuの通常経路では10.0.0.0/24宛て応答がLANルーターへ向かう可能性がある。一方、既存記録ではVPSから旧Windows/WSL2へのSSHが成功しているため、Raspberry Piでsource NATが設定されている可能性がある。
Raspberry Piで次を確認する。
sudo nft list ruleset
sudo iptables-save
判断:
10.0.0.0/24 via 192.168.68.141の戻り経路が必要この時点ではroute、NAT、firewallを変更しない。現在成立している方式を特定してから、必要な変更を別途レビューする。
Ubuntuで実行する。
nmcli -f DEVICE,TYPE,STATE,CONNECTION device status
ping -c 3 -W 2 192.168.4.1
timeout 5 bash -c '</dev/tcp/192.168.4.1/2101'
VRSCへのpingとTCP 2101が成功しない場合はproxyを開始しない。
ss -lnt '( sport = :22101 )'
出力が空であることを確認する。使用中なら停止させず、別の候補ポートを選ぶ。
socatの有無を確認command -v socat
未導入の場合、パッケージ導入は環境変更になるため、その場で勝手に実行しない。導入の必要性、パッケージ名、削除方法を示して承認を得る。
専用ターミナルで実行する。ペイロード内容を画面へ出さず、接続イベントだけを表示する。
socat -d -d \
TCP4-LISTEN:22101,bind=192.168.68.134,reuseaddr,fork \
TCP4:192.168.4.1:2101
別ターミナルで待受を確認する。
ss -lntp '( sport = :22101 )'
合格条件:
192.168.68.134:22101だけでLISTENする0.0.0.0:22101や公開インターフェースでLISTENしない同一LANの別端末が利用できる場合、その端末から実行する。
nc -vz -w 5 192.168.68.134 22101
socat側でacceptと192.168.4.1:2101への接続が記録されることを確認する。nc -zはTCP接続確認だけで、NTRIPの上りメッセージやRTCM内容までは検証しない。
起動した専用ターミナルでCtrl+Cを押す。
ss -lnt '( sport = :22101 )'
出力が空になり、待受が残っていないことを確認する。
Phase 2と同じコマンドでUbuntuの一時proxyを起動する。
VPSで実行する。
nc -vz -w 5 192.168.68.134 22101
VPS、Raspberry Pi、Ubuntuの各地点で次を確認する。
socatのaccept192.168.4.1:2101への接続| 到達状況 | 主な確認先 |
|---|---|
| VPS→Piも失敗 | WireGuard handshake、VPS/Pi firewall |
| VPS→Pi成功、Ubuntu失敗 | Pi forwarding/NAT、戻りroute、Ubuntu firewall |
| Ubuntu proxyへ接続、VRSC側失敗 | Ubuntu Wi-Fi、VRSC電源、192.168.4.1:2101 |
| 一度だけ成功し再接続不可 | socat子process、socket close、VRSCのclient解放待ち |
firewallやrouteを変更する前に、失敗地点と必要最小限の変更案を記録し、レビューする。
Ubuntuの一時proxyをCtrl+Cで終了し、待受が消えたことを確認する。VPSとRaspberry PiにはこのPhaseで常設設定を追加しないため、追加のロールバックはない。
各Phaseで最低限、次をIssue #22へ残す。
nc -zによる確認はTCP経路だけを検証する。次はAndroid/DG-PRO1RWSを接続する後続Trackで確認する。
RXM-SFRBXNAV-PVTVRSCPhase 1〜3がすべて成功した場合:
失敗した場合:
inconclusiveまたはneeds-reviewとして整理するPhase 1〜3を読み取り確認の範囲で実施した。route/NAT/firewallへの変更は行っていない。
192.168.68.141ではなく、実際には192.168.68.130だった（DHCPによる再割当と推定）。mDNS名vpsgateway.local、MACアドレス接頭辞b8:27:eb（Raspberry Pi Foundation）、SSH port 22 openから特定し、ユーザーへ確認のうえ採用した。eth0ではなく無線wlan0だった（eth0はDOWN）。docs/wireguard-setup.md作成時の想定（有線LAN固定）と異なる。ssh -i ~/.ssh/id_ed25519_vpsgateway akira@192.168.68.130を使用した（ユーザー確認済み）。VPSは既存の~/.ssh/configエイリアスkeinafarm（keinafarm.net→162.43.33.56、user akira）を使用した。sudoが全ホストでパスワード必須のため、sudo wg show/nft list ruleset/iptables-saveは取得できなかった。非rootで得られる情報で代替確認した。
10.0.0.2): ping 3/3成功（28-50ms）192.168.68.130): ping 3/3成功（23-30ms）wg0は累積RX 207MB/TX 175MBで継続的な通信実績あり。ip routeで192.168.68.0/24がdev wg0（scope link）に向いており、AllowedIPs設定通りUbuntu宛パケットもwg0へ送出される192.168.68.134)ping: 3/3失敗（予備確認のため、この時点では中止と断定しなかった）ip route get 10.0.0.1はvia 192.168.68.1 dev enp2s0（LANルーター経由のdefault route）で、10.0.0.0/24宛の専用routeは存在しない/proc/sys/net/ipv4/ip_forwardが現在0（無効）。一方/etc/sysctl.confにはnet.ipv4.ip_forward=1が記載されており、設定ファイルと実際のカーネル値が一致していない。Piのuptimeは2026-07-08からで、その間に再起動はしていない。原因（起動時適用失敗か、後から他プロセスが上書きしたか）は未特定。この状態ではPiがWireGuard(wg0)↔LAN(wlan0)間でIPパケットを転送しないため、NAT方式か静的routeかによらずVPS→Ubuntu間の疎通はそもそも成立しない。Phase 1の合格条件のうち「応答経路またはRaspberry PiのNAT方式を説明できる」は、「Pi側のip_forward無効化が転送そのものを止めている」という上位の原因まで特定できたが、nft/iptables未確認のためNATの有無自体は未確定のまま。
判断: Phase 1は中止条件「既存NAT/routeを説明できず、変更が必要」に該当する。Pi設定は変更せず、ユーザーへ最小変更案の承認を求める。
Ubuntu単体、Pi/VPSに依存しない範囲で実施し、合格条件をすべて満たした。
22101/tcpは未使用、socatは/usr/bin/socatに導入済み（新規インストール不要）socat -d -d TCP4-LISTEN:22101,bind=192.168.68.134,reuseaddr,fork TCP4:192.168.4.1:2101を起動し、ss -lntpで192.168.68.134:22101のみのLISTENを確認（0.0.0.0等への公開なし）nc -vz 192.168.68.134 22101を2回実行して代用。いずれも成功し、socatログで接続ごとに子プロセスがforkされ、都度192.168.4.1:2101へ新規TCP接続（送信元192.168.4.2）を確立、EOF後に子プロセスが正常終了、直後の再接続も成功したことを確認したpkillで停止後ss -lntにLISTENなし、pgrepでプロセス残存なしを確認Phase 2のproxyを維持したまま、VPSからnc -vz -w 5 192.168.68.134 22101を実行し、timeout（"Operation now in progress"）で失敗した。VPS側wg0のRX/TXバイト数はわずかに増加しており、SYN相当のパケットは送出されたがハンドシェイクは完了しなかった。この結果はPhase 1で判明したPiのip_forward=0と整合する。Ubuntu側の戻り経路（10.0.0.0/24への専用route要否）は、Pi側の転送が復旧してから改めて検証する。
nft/iptablesによるNAT設定の有無（sudo制約で未確認）10.0.0.0/24 via 192.168.68.130等の戻り経路が別途必要かどうか（Pi転送復旧後に再検証）ip_forwardがなぜ/etc/sysctl.confの設定と食い違ったかnet.ipv4.ip_forwardを1へ再設定する変更（最小案・影響範囲・ロールバックを別途提示）についてユーザー承認を得る192.168.68.130、wlan0）に合わせて修正するoutcomeは本Phaseの結果のみでは確定せず、needs-reviewとして整理する作業専用ユーザーdroggervrsc（VPS WireGuardゲートウェイPiへの作業アクセス）を使い、ユーザー承認済みの一時変更としてPiのip_forwardを0→1へ切り替えたうえでPhase 1〜3を再実施した。試験後は1→0へロールバック済みで、route/NAT/firewallの追加変更、WireGuard再起動、Pi/VPS再起動、sysctl永続化、proxyのsystemd化は行っていない。
hostname=vpsgateway、wlan0=192.168.68.130/24、wg0=10.0.0.2/24、default via 192.168.68.1 dev wlan0ip_forward（/proc/sys/net/ipv4/ip_forwardおよびsysctl）=0（前回セッションから未変更）sudo -n /usr/bin/wg show: handshake 49秒前、transfer: 542.74 KiB received, 1.96 MiB sentsudo -n /usr/sbin/nft list rulesetとiptables-saveが取得できた。POSTROUTINGチェーンにoifname "wlan0" ... masquerade（iptables-save側は-A POSTROUTING -o wlan0 -j MASQUERADE）を確認し、VPS―Ubuntu間の戻り経路はPiの静的routeではなくMASQUERADE(SNAT on wlan0)方式であることを確定した。filterテーブルは出力に現れず、forward制限は無い（デフォルトACCEPT運用と判断）。実行コマンド: sudo -n /usr/sbin/sysctl -w net.ipv4.ip_forward=1 → 結果 net.ipv4.ip_forward = 1。
VPS(keinafarm)から実行。
10.0.0.2): ping 3/3成功(26-96ms)192.168.68.130): ping 3/3成功(23-27ms)192.168.68.134): ping 3/3成功(31-35ms、ttl=63) — 前回セッションの3/3失敗から解消。ttl=63はPi経由で1ホップ減っていることと整合する。合格条件（WireGuard handshake正常、VPS→Pi到達、応答経路またはNAT方式を説明できる、Ubuntu ping結果の記録）をすべて満たした。
Ubuntu(192.168.68.134/192.168.4.2)で実行。
nmcli: 有線LAN・VRSC Wi-Fiとも接続済みip route get 192.168.4.1: wlx90de80ecd0ce経由open22101/tcp未使用、socat導入済みsocat -d -d TCP4-LISTEN:22101,bind=192.168.68.134,reuseaddr,fork TCP4:192.168.4.1:2101を起動し、ss -lntpで192.168.68.134:22101のみのLISTENを確認（0.0.0.0等への公開なし）VPS(keinafarm)からnc -vz -w 5 192.168.68.134 22101を2回実行し、いずれもsucceeded。
裏付け:
192.168.68.130:37334、2回目は192.168.68.130:54622から接続を受理した（接続元がPiのLANアドレスに見え、12.1で判明したMASQUERADE方式と整合）。それぞれ新規に192.168.4.1:2101へ接続（送信元192.168.4.2）、データ転送後EOFでexit status 0の正常終了、直後の再接続も成功。wg show: handshakeが11秒前に更新、received transferが542.74 KiB→544.86 KiBへ増加。nc -zで確認できたのはTCP経路のみであり、RTCM、RXM-SFRBX、NAV-PVT、NTRIP mountpoint、RTK FIXは未確認・未検証のままである。
socatをSIGTERMで終了（ログでexit(143)を確認）、ss -lntでLISTENなし、pgrep socatでプロセス残存なしを確認sudo -n /usr/sbin/sysctl -w net.ipv4.ip_forward=0 → 結果 net.ipv4.ip_forward = 0/etc/sysctl.conf・/etc/sysctl.d/の編集、WireGuard/Pi/VPS再起動、sudoers変更、proxyのsystemd化は行っていないVRSC、RTK FIX/FLOAT/単独測位（Android/DG-PRO1RWSを使う後続Trackで確認する）ip_forwardが/etc/sysctl.confの記載(1)と食い違っていた原因（起動時適用失敗か後からの上書きか）は未特定のまま。今回は毎回sysctl -wで明示的に1へ切り替える運用としたncで代用）Phase 1〜3の合格条件をすべて満たし、VPS→VRSCまでの双方向TCP経路が成立することを確認した。往路はWireGuard→Pi転送(ip_forward=1時)→PiのMASQUERADE、復路も同じ経路を逆向きに通る対称NAT構成である。既存WireGuard・VPS・Ubuntu・VRSC側の常設設定は変更していない。Android/DG-PRO1RWSを使う遠隔統合検証は、本結果を踏まえて別Trackとして起票する。