今回も旅の話ではありません。
自宅や拠点のカメラを外部に公開せずに Synology の Surveillance Station で参照したい場合、リバースSSHトンネルとローカルプロキシを組み合わせる手法が有効です。ここでは、GL‑MT3000（GL.iNet 製の OpenWrt 搭載ルータ）上で稼働するカメラを対象に、実際に運用した手順と運用上の注意点を説明します。
本ブログの内容をGemini Notebookでスライドにまとめましたので、こちらも参考にしてください。
構成の概要
基本的な構成は次のとおりです。カメラは GL‑MT3000 上でローカルに配信し、GL‑MT3000 から Synology に対してリバースSSHトンネルを張ります。Synology 側ではローカルプロキシが LAN 側の受け口を持ち、内部でトンネル先のローカルポートに接続することで、Surveillance Station はローカル接続のみでカメラ映像を取得できます。
[Camera on GL‑MT3000 (OpenWrt)] localhost:<CAM_PORT>
↑
リバースSSHトンネル (ssh -R)
↓
[Synology] 127.0.0.1:<TUNNEL_PORT> ← local proxy ← 192.168.x.y:<PROXY_PORT>
↓
Surveillance Station (rtsp://127.0.0.1:<TUNNEL_PORT>/...)
この構成により、外部にポートを開放することなく監視を実現できます。
実行手順（概要）
- Synology 側でプロキシを一時停止して、トンネル用のポートを空けます。
- GL‑MT3000（OpenWrt）側でリバースSSHトンネルを作成します。鍵認証を用い、
ServerAliveInterval等のオプションで接続安定化を図ります。 - Synology 側でプロキシを再起動し、LAN 側の受け口から内部のトンネルポートへ接続するよう設定します。
- 動作確認として Synology から RTSP の OPTIONS 等を投げ、
RTSP/1.0 200等の応答を確認します。
コマンド例は公開用に一般化してありますので、実環境ではプレースホルダを置き換えてご利用ください。
トラブルシュートのポイント
- ポート競合：Synology 側でプロキシが先に同ポートを占有していると、リバースSSHトンネルのリモートバインドが失敗します。対処は「プロキシ停止 → トンネル作成 → プロキシ起動」の順です。
- 接続タイムアウト：127.0.0.1 に接続してタイムアウトする場合は、トンネルが確立しているか、プロキシが正しいリモートポートに接続しているかをログで確認してください。
- OpenWrt 固有の注意：GL‑MT3000 の OpenWrt 環境ではファイアウォール設定や SSH クライアントのパスが影響する場合があります。必要に応じてローカル出力を許可してください。
- ログ確認：プロキシログと SSH の接続ログを照合すると原因特定が早まります。公開する際はログの匿名化を行ってください。
恒久化と運用
リバースSSHトンネルは切断されることがあるため、自動復旧の仕組みを導入することを推奨します。GL‑MT3000（OpenWrt）環境では autossh を用いる方法が安定的です。autossh が利用できない場合は、/etc/rc.local への追記や crontab @reboot、あるいは init スクリプトで起動する方法が実用的です。ログは定期的にローテーションし、切断や異常を早期に検知する運用を行ってください。
Tailscale の使いどころ
今回のように GL‑MT3000 から Synology への SSH が通常経路で到達可能であれば、リバースSSHトンネルのみで完結します。一方で、GL‑MT3000 を外出先に持ち出す、モバイル回線を利用する、ISP の CGNAT 下にある、あるいはルーター設定を変更できないといった状況では、Tailscale による仮想ネットワークが有効です。Tailscale を導入すると両端が仮想的に同一ネットワークに見えるため、到達性と運用の柔軟性が向上します。
まとめ
GL‑MT3000（GL.iNet、OpenWrt 搭載）を用いたリバースSSHトンネルとローカルプロキシの組み合わせは、外部公開を行わずに遠隔カメラを Synology で参照するための実用的な手法です。適切な恒久化とログ監視、鍵管理を行うことで安定した運用が可能となります。