はじめに

SORACOMのSIMをまともに使ったことがなかったので検証してみました。

検証の背景

SORACOMを使ってデバイスからAmazon API Gatewayにセキュアに接続したいです。
VPG Type-Fを使えば閉域網になるため最も安全ですが、まずは手軽で安く使えるVPG Type-Eで検証したいと思います。
- VPG Type-EでグローバルIPを固定し、API GatewayのリソースポリシーでそのグローバルIPにしぼります。
- かつ暗号処理のオフロードとしてBeamも使いたいので、http -> https変換をsoracom網で行ったうえでAPI Gatewayにつなげてみます。

主な利用サービスと検証ポイント

SORACOM VPG Type-Eとは

インターネット接続ができ、グローバルIPも固定できるサービスのようです。
https://soracom.jp/services/vpg/

SORACOM Beamとは

SIMからインターネットに出るのですが、その前にSORACOM網のなかで暗号化や接続先の切り替えなどをやってくれるようです。
- https://soracom.jp/services/beam/

両方使うとどうなるのか？

私はどちらも使うのが初めてです。
Type-Eを使うとインターネット接続ができるというのはわかるのですが、その状態でBeamを使った場合のイメージが湧きませんでした。というのも私はBeamは全てのhttpをhttpsに変換するサービスというイメージを抱いていたので、通常のインターネット接続に何らかの影響がでるのでは？というイメージを持っていました。サイトの説明をみると両立できるように見えましたが、SORACOMの練習も兼ねて実際に検証してみました。

ラズパイ4の環境と設定

ラズパイ4にsoracom SIMの入ったUSBドングルをつなげています。

Raspberry Pi

Raspberry Pi 4 Model B / 4GB を使い、ヒートシンクもつけています。
https://www.switch-science.com/catalog/6030/
https://www.switch-science.com/catalog/5986/
- なお、このヒートシンク(PIMORONI-COM1203)はギリギリサイズなので、つけるときには少し注意が必要です。GPIOピンに接触しないように気持ち下に離すといいです。なお両面テープの接着力は強力ではないため失敗しても付け直しは可能です。
なお、SORACOM SIMを検証するのにラズパイを使う必然性はありません。今回は環境的に独立させたほうが検証が楽であり、かつWindows10などではバックグラウンドで様々な通信をされて通信費用が嵩んでしまうため、Raspbian OSなラズパイを使っています。

SORACOM Air

soracom SIMはplan-dの標準サイズを使っています。
- s1.standard(512 kbps)を利用してます。
- https://soracom.jp/products/sim/plan-d/

USBドングル

USBドングルはLTEも使えるHuawei MS2372h-607を使っています。
- https://soracom.jp/products/module/ms2372h_607/

以下はドングルにSIMを挿した状態です。

ドングルは幅があります。ラズパイ4のUSB口に直接挿すと隣にUSBを挿すのがきつくなるため、USBハブを使っています。
　※なお、ラズパイの背面には小型のタッチモニタをつけています。YOMON8さんが勧めていたのものを買いました。
　　　https://yomon.hatenablog.com/entry/2020/09/monitor_rpi

ラズパイでSIMのセットアップ

設定方法は以下の通り。
- https://dev.soracom.io/jp/start/device_setting/
- 一度自宅のwifiにつなげてからsetup_air.shを実施しましたが、10分くらい？かかりました。

私の場合、コマンド完了直後はSIMの接続が有効化されていないようでした。OS再起動後に以下コマンドを実施すると反応がありました。

root@raspberrypi:~# ifconfig ppp0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.213.188.XXX  netmask 255.255.255.255  destination 10.64.64.XXX
        ppp  txqueuelen 3  (Point-to-Pointプロトコル)
        RX packets 16  bytes 1061 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17  bytes 818 (818.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wifi有効状態でも、ルーティング的にsimのpoint to point接続のほうが優先されているようでしたが、念の為wifiはOFFにしておきました。

wifiを無効化した状態でも、ブラウザでふつうにインターネット接続ができました。
とりあえず SORACOM Airは正常に使えているようです。

SORACOM Airの使用状態でグローバルIPを確認すると、soracom所管のIPのようです。

root@raspberrypi:~# curl ifconfig.io
103.67.xxx.xxx

VPG Type-Eの設定

費用は以下の通りです。
- https://soracom.jp/services/vpg/price/
- 利用料金は安いのですが、セットアップに 198 円/回 (日本カバレッジの場合)かかるという点が検証の注意ポイントです。

Type-Eのセットアップ

Type-Eの手順は以下を参考にしました。
- https://dev.soracom.io/jp/docs/gate_access_between_devices/
- ただし今回はGateを使わないので、「ステップ3: デバイス間通信を利用するIoT SIMをグループに登録する」までしか実施していません。

VPGに今回のSIMが所属しているグループを入れると、以下のようになります。

ラズパイを再起動します。(そこまでしなくてもいいのかもしれませんが念の為)
スマホであれば機内モードのオン・オフでいいようです。
遠隔地にある場合はSORACOMのコンソールからSIMの「セッション切断」を行うことで、デバイスからの再接続時に有効化できるようです。

状態の確認

再起動後、グローバルIPを確認すると、AWS東京リージョンのIPのようです。
（soracom側のAWSのインターネットゲートウェイのIPなんですかね？）

root@raspberrypi:~# curl ifconfig.io
13.231.XXX.XXX

他のユーザと共有されているグローバルIPなのかは私だけでは確認できませんが、以下の情報を見ると、他ユーザとは共有されなさそうな書きっぷりです。

*1 VPG（Virtual Private Gateway）は、SORACOM プラットフォーム上のお客様専用のネットワークゲートウェイ（インターネット側の出口）です。

https://soracom.jp/press/2020071403/

なお、インターネット接続もブラウザで正常にサイト閲覧ができました。

API Gatewayの設定

前提

詳細は省きますが、検証用として以下のPetStoreというサンプルをREST APIとして作成済みです。
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-create-api-from-example.html
エンドポイントはリージョン（インターネットフェイシング）型としています。HTTP APIだとリソースポリシーが使えないのでREST APIを使っています。

リソースポリシーで実行できるIPを制限しているため、ラズパイからType-Eを有効化した状態でそのまま叩くと拒否されます。

root@raspberrypi:~# curl https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/pets/2/
{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:ap-northeast-1:************:xxxxxxxx/dev/GET/pets/2/"}
root@raspberrypi:~#

リソースポリシーの編集

対象のAPIのリソースポリシーを編集し、さきほどのType-EのグローバルIPを登録します。(リソース名やIPは読み替えてください)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:ap-northeast-1:<account id>:<resource id>/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "13.231.XXX.XXX/32"
                }
            }
        }
    ]
}

テスト

APIを再デプロイし、ラズパイからさきほどと同じGETメソッドを実行すると、正常に取得できていることが確認できました。

root@raspberrypi:~# curl https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/pets/2/
{
  "id": 2,
  "type": "cat",
  "price": 124.99
}
root@raspberrypi:~#

Beamの設定

Beamのセットアップ

今回のSIMが所属しているSIMグループにBeamの設定を追加します。
- 転送先
  - 今回のAPI Gatewayのエンドポイントをそのままホスト名とパスに分解して設定しました。

設定すると以下のようになります。

テスト

ラズパイからBeamで設定したhttpのエントリポイントを叩いてみます。

root@raspberrypi:~# curl http://beam.soracom.io:8888/api-pet01/
{
  "id": 2,
  "type": "cat",
  "price": 124.99
}
root@raspberrypi:~#

正常にAPIが実行されました。
レスポンスも、API Gateway直打ちと同一の内容です。

まとめ

VPG(Type-E)でBeamを使う場合は基本的には固定GIPのインターネット接続でしかなく、Beamであらかじめ指定したURLのみBeamとして扱われるということのようです。
- SORACOM AirではグローバルIPがSORACOM所管のものとなり、VPG Type-EではAWS所管のものに切り替わります。
- VPG Type-E下でBeamを使う場合でもソースのグローバルIPはVPG Type-EのGIPのままです。
- ですので既存のインターネット接続をしつつ、API GatewayはBeamで使う、ということができることがよくわかりました。

以上です。