この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、菊池です。
IoTデバイスへのオンデマンドでのリモートアクセスを提供するサービスSORACOM Napterを使って、Raspberry Pi 3へのSSHアクセスを試してみました。
SORACOM Napterについては非常にシンプルで特に迷う部分もありませんでしたが、接続先のRaspberry Pi 3がSORACOM Air SIM以外のローカルネットワークにも接続していたため、デバイス内でのルーティング設定が必要でした。
接続構成
接続構成は以下の通り。
- IoTデバイス
- Raspberry Pi 3 Model B
- LTEドングル docomo L-02A
- SORACOM IoT SIM
- 特定地域向けSIM plan-D
SORACOM Napterのリモート接続
オンデマンドリモートアクセス
まずはデバイス側でppp接続を行い、SIMのステータスがオンラインであることを確認します。コンソールから、対象のSIMを選び、[操作]を選択します。
メニューから[オンデマンドリモートアクセス]を選択しましょう。
デバイス側のポートとアクセス可能な時間、アクセス元のIPを選びます。なお、SORACOM Napterは特定地域向けで1SIMあたり300 円/月の利用料が発生しますが、1アカウント1月1SIMまでの無料枠があります。
すると、接続用のIPアドレスとポートが表示されます。このIP/ポートにてSSH接続を試します。
リモート接続
ここで、ちょっと問題が発生しました。指示通りに接続しても一切レスポンスがない状態となっていました。
$ ssh -p xxxxx skikuchi@3.xxx.xxx.xxxSORACOM Napterには特に他に設定する項目もないのでしばらく悩みましたが、Raspberry Pi 3側のルートテーブルに問題があることに気がつきました。
今回利用したRaspberry Pi 3は、IoT SIM以外に、EthernetでローカルのネットワークにスタティックIPで接続していました。
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:6f:c1:e5 brd ff:ff:ff:ff:ff:ff
inet 192.168.99.238/24 brd 192.168.99.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::def6:f5f1:baed:60aa/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:3a:94:b0 brd ff:ff:ff:ff:ff:ff
4: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 10.215.166.57 peer 10.64.64.64/32 scope global ppp0
valid_lft forever preferred_lft foreverEthernet側にデフォルトルートを設定していましたので、ルートテーブルを確認すると以下のようになっていました。
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0
10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0デフォルトルートがeth0側を向いているため、ppp0からのSSHアクセスに対するレスポンスが正しく返せていないようです。Napterからアクセスしてくるソースアドレスがわからないので、とりあえず、eth0側より小さいメトリックでデフォルトルートを追加しました。
$ sudo ip route add 0.0.0.0/0 via 10.64.64.64 metric 100 dev ppp0これでルートテーブルは以下のようになりました。
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.64.64.64 0.0.0.0 UG 100 0 0 ppp0
default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0
10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0これで再度、Napterのリモートアクセスを試した結果、ようやくSSH接続ができました。
$ ssh -p xxxxx skikuchi@3.xxx.xxx.xxx
:
:
skikuchi@3.xxx.xxx.xxx's password:
:
:
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 7 14:20:01 2020 from xxx.xxx.xxx.xxx
$Napterでのリモートアクセスはできましたが、このままでは、デフォルトルートとして常時SORACOM IoT SIM側を利用してしまうため、必要な宛先の範囲だけIoT SIMを使うようにします。まず、NapterでログインしてきているIPアドレスを確認します。
$ w -i
14:51:11 up 34 min, 3 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
skikuchi pts/0 100.127.10.16 14:50 2.00s 0.21s 0.03s w -iどうやら、Napterでオンデマンドリモートアクセスする際のアクセス元IPは、デバイスから見ると100.68.0.0/10の範囲（RFC6598）となってそうです。改めてルートテーブルを以下のように設定しました。
$ sudo ip route add 100.64.0.0/10 via 10.64.64.64 metric 100 dev ppp0
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.99.254 0.0.0.0 UG 202 0 0 eth0
10.64.64.64 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
100.64.0.0 10.64.64.64 255.192.0.0 UG 100 0 0 ppp0
192.168.99.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0これで再度、Napter経由でのSSHを確認したところ、問題なく接続ができました。
まとめ
SORAOM Napterによるオンデマンドリモートアクセスを試しました。IoT SIMにさえ接続できていれば、必要に応じでリモートから簡単にアクセスが可能です。一方で、複数のネットワークに接続するデバイスの場合には、デバイスのルートテーブルを要確認という話でした。
7
