本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「閉域網内でのAWS Systems ManagerによるIoT機器のリモートアクセスの構成と注意点」を再編集したものです。
IoTデバイスへのリモートアクセスというのは、IoTプロジェクトでもよくある要件です。その上で、セキュアなリモートアクセスを実現する手段の一つとして、閉域ネットワーク（プライベートネットワーク）が検討されます。
SORACOM では、 SORACOM Napter もしくは SORACOM Gate で IoT SIM を使用するデバイスへのリモートアクセスが可能です。下記ドキュメントにも記載のとおり、SORACOM Napter は一時的なリモートアクセス、 SORACOM Gate は定常的なリモートアクセスに向いています。
AWS Systems Manager
SORACOM プラットフォームから閉域接続できる接続先の 1 つに AWS があります。AWS には AWS Systems Manager というサービスがあります。
AWS Systems Manager とは簡単に言うと Amazon EC2 やオンプレミスのサーバーの運用管理ツールです。サーバーへリモートからアクセス・コマンドを実行する機能だけでなく、 OS ・アプリケーション設定を管理する機能やそれらを自動化する機能などが提供されており、サーバーの運用管理に役立ちます。AWS Systems Manager の RunCommand や Session Manager というリモートアクセスに関わる機能だけを見ても、デバイス側の OS ユーザーを管理する必要がなくアクセス管理を AWS IAM に統合できる、接続履歴・コマンド履歴をAWS上で記録できるといったメリットがあります。
AWS Systems Manager の管理対象とするにはサーバーへ SSM Agent をインストールしますが、Raspberry Pi のようなシングルボードコンピュータで SSM Agent のサポートしている OS が動くデバイスであれば、 SSM Agent をインストールし AWS Systems Manager の管理対象（マネージドノード）とできます。ルーターや何らかのデバイスで NAPT 越しに AWS Systems Manager に接続する場合でも、NAPT している機器でポートフォワードのような設定なしにリモートアクセスできます。
今回は Amazon VPC との閉域接続サービス「SORACOM Canal」 と AWS Systems Manager を使って閉域でデバイスへリモートアクセスする構成について検証しました。またその注意点についても判明したので紹介します。
構成
今回検証した構成は以下のようなものです。SORACOM Canal と Amazon VPC 間は VPC ピアリングもしくは Transit Gateway で接続できますが、今回は VPC ピアリングを利用しました。閉域でのリモートアクセスを試すため、Virtual Private Gateway (VPG) にも Amazon VPC にもインターネットへの経路は設けていません。デバイスから AWS Systems Manager へは VPC endpoint で接続しました。デバイスは Raspberry Pi と SORACOM Onyx LTE USB ドングル を使用しました。
手順
今回の検証手順を説明します。AWS のリージョンは東京リージョン (ap-notheast-1) を前提としています。
1. Amazon VPC の作成
AWS マネージメントコンソールから Amazon VPC を作成します。VPC ダッシュボードの「VPC を作成」から簡単に作成できます。
今回は閉域での検証のためパブリックサブネット と NAT ゲートウェイは不要です。
2. VPG / SORACOM Canal 設定
下記の『ステップ 2: VPG を作成し Canal を構成する』のように VPG の作成と SORACOM Canal を設定します。下記の手順ではインターネットゲートウェイを ON としていますが、今回は閉域で検証のため OFF として VPG からインターネットへ通信できないようにします。
3. VPC エンドポイント / Route53 Inbound Resolver / Route53 プライベートホストゾーン作成
作成した Amazon VPC へ VPC エンドポイント、 Route53 Inbound Resolver 、 Route53 プライベートホストゾーンを追加します。
VPC エンドポイントと Route53 Inbound Resolver にはセキュリティグループが必要なのであらかじめインバウンドルールに以下のようなルールを設定し作成します。VPG の IPv4 アドレス空間は、手順『2. VPG / SORACOM Canal 設定』で紹介したドキュメント記載のとおり、 VPC ピアリングのリクエスタ VPC CIDR になります。
VPC エンドポイント用
| プロトコル | ポート | ソース |
| TCP | 443 | {VPG の IPv4 アドレス空間} |
Route53 Inbound Resolver 用
| プロトコル | ポート | ソース |
| TCP | 53 | {VPG の IPv4 アドレス空間} |
| UDP | 53 | {VPG の IPv4 アドレス空間} |
VPC エンドポイントを作成します。VPC エンドポイントは閉域で AWS サービスと通信するのに必要となります。 今回作成した VPC エンドポイントは以下です。
| サービス | タイプ | 補足 |
| com.amazonaws.ap-northeast-1.ssm | インターフェイス型 | SSM Agent が AWS Systems Manager へアクセスするのに必要。 |
| com.amazonaws.ap-northeast-1.ssmmessages | インターフェイス型 | SSM Agent が AWS Systems Manager へアクセスするのに必要。 |
| com.amazonaws.ap-northeast-1.ec2message | インターフェイス型 | SSM Agent が AWS Systems Manager へアクセスするのに必要。 |
| com.amazonaws.ap-northeast-1.s3 | インターフェイス型 | Amazon S3 の VPC エンドポイント。SSM Agent のインストールや SSM RunCommand のような S3 バケットへアクセスする機能を利用するのに必要。 |
インターフェイス型の VPC エンドポイントには Amazon VPC 内にネットワークインターフェイスが作成され、ssm.ap-northeast-1.amazonaws.com や ssmmessages.ap-northeast-1.amazonaws.com といった具合に各サービスの DNS 名が割り当てられます。インターフェイス型エンドポイントのある Amazon VPC から各 AWS サービスへアクセスする際には、Amazon VPC 内からアクセスできるAmazon DNS サーバーで名前解決されプライベート IP アドレスで接続します。VPC ピアリングや専用線、 VPN で Amazon VPC 外 からアクセスする場合には Route 53 Inbound Resolver を設定することで対象のAmazon VPC 内で名前解決できます。
しかし `com.amazonaws.ap-northeast-1.s3` のVPCエンドポイントは少々仕様が異なり、サービスの DNS 名 s3.ap-northeast-1.amazonaws.com が割り当てられません。vpce-XXXXXXXXXXXXXXXXX-XXXXXXX.s3.ap-northeast-1.vpce.amazonaws.com のような VPC エンドポイント固有の DNS 名のみが割り当てられています。つまり Amazon S3 にアクセスする際のs3.awsamazon.com や {S3 バケット名}.s3.awsamazon.com のような DNS 名では S3 バケットへアクセスできません。そのため Route 53 プライベートホストゾーンを作成し s3.ap-northeast-1.amazonaws.com の名前解決で vpce-XXXXXXXXXXXXXXXXX-XXXXXXX.s3.ap-northeast-1.vpce.amazonaws.com を返します。簡記すると以下のようなイメージです。
続いて デバイスから VPC 内の VPC エンドポイントの名前解決ができるように SIM グループへ カスタム DNS を設定します。 上記の『1. Amazon VPC の作成』で作成したRoute 53 Inbound Resolver は VPC 内に仮想ネットワークインターフェイスを持っており、IP アドレスが振られています。[IP アドレス] に設定する DNS サーバーの IP アドレスはこの Route 53 inbound Resolver の IP アドレスです。
Route 53 inbound Resolver の詳細画面から IP アドレスは確認できます。
3. Raspberry Pi へ SSM Agent インストール
Raspberry Pi へ SSM Agent をインストール・アクティベーションします。詳細は下記 AWS ドキュメントをご確認ください。SSM Agent は AWS にて公開されている S3 バケットからダウンロードしますが、手順 1 にて VPC エンドポイントを追加しているので、すでに VPG に収容されインターネットと通信できないデバイスであってもダウンロードできます。
4. 確認
AWS Systems Manager のコンソールにデバイスが表示されるか確認します。ホスト名 (= コンピューター名) で検索すると見つけやすいです。注意点として後述しますが、マネージドノード一覧にデバイスが表示されない場合があります。
RunCommand を設定・実行し接続を確認します（マネージドノード一覧に表示されなくても RunCommand は実行できます）。使用するドキュメントは AWS-RunShellScript です。これは Linux に対して任意のシェルスクリプトを実行できるものになります。
今回は SSM Agent を導入した Raspberry Pi にアクセスできているか確認するため、ここでは `hostname` コマンドと `ifconfig` コマンドを実行してみます。
ターゲットを選択します。こちらもホスト名で検索すると見つけやすいです。マネージドノード一覧に表示されていなかった場合、ターゲット一覧ではアクティベーション ID で検索すると対象が表示されますが、 Ping ステータスは `ConnectionLost` となっています。
RunCommand ではコマンドの結果を S3 バケット・CloudWatch Logs へも記録できます。今回はこれらは設定せず実行します。
実行後、しばらくするとコマンドのステータスが成功となります。インスタンス ID をクリックしてコマンド結果を確認します。
hostname と ifconfig の結果が Output 欄で確認できます。SSM Agent を導入した Raspberry Pi のホスト名と IP アドレスが確認できると思います。
注意点
1. マネージドノード一覧に表示されない
手順 4 でマネージドノード一覧デバイスが表示されない場合があると述べましたが、 これは SSM Agent の仕様によりエラーが発生するためです。 あくまで表示されないだけで AWS CLI だと下記のように情報を確認できます。ただし OS の種類、ホスト名など通常取得できる情報は取得できません。
$ aws ssm describe-instance-information --filters "Key=InstanceIds,Values=mi-XXXXXXXXXXXXXXXXX" { "InstanceInformationList": [ { "InstanceId": "mi-XXXXXXXXXXXXXXXXX", "PingStatus": "ConnectionLost", "ActivationId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "IamRole": "example", "RegistrationDate": "2022-11-17T00:00:00.000000+00:00", "ResourceType": "ManagedInstance", "SourceId": "mi-XXXXXXXXXXXXXXXXX", "SourceType": "AWS::SSM::ManagedInstance" } ] }
SSM Agent は AWS Systems Manager へ送信する情報の 1 つに IP アドレスがありますが、SSM Agent は Up していない NIC、 ループバックインターフェース、PPP インターフェースをスキップして IP アドレスを取得します。SIM のみでネットワークに接続する場合、Raspberry Pi の イーサネットインターフェース・無線 LAN インターフェースに IP が振られず、SSM Agent は IP アドレスが取得できません。 AWS Systems Manager へデバイスの情報が送信された際に下記のエラーとなっています。Raspberry Pi OS の場合、/var/log/amazon/ssm/errors.log へ出力されています。AWS Systems Manager 側でも IP アドレスを含めたそのほかの情報がマネージドノードに表示されません。
ERROR [ssm-agent-worker] [HealthCheck] error when calling AWS APIs. error details - InvalidParameter: 1 validation error(s) found. - minimum field size of 1, UpdateInstanceInformationInput.IPAddress.
このエラーについては古いバージョンの SSM Agent に関するものですが GitHub の Issue にもあがっています。 この Issue で記述されているとおり、当該処理をスキップして自前で SSM Agent をビルドすると回避できるでしょう。
なお、 LTE ゲートウェイ経由で SORACOM プラットフォームへ接続するデバイスや SORACOM Arc で接続するデバイスであれば有線や Wi-Fi で接続するかと思います。その場合、イーサネットインターフェース・無線 LAN インターフェースに IP アドレスが振られるのでこのエラーは発生せずマネージドノード一覧に表示されます。
2. AWS Systems Manager の料金
AWS Systems Manager にはリージョンごとにオンプレミスインスタンスティアと呼ばれるレベルが存在します。デフォルトはスタンダードで、 1 リージョンあたり1,000 台までのオンプレミスのサーバー・デバイスが登録できます。しかし、それを超える場合は自動でアドバンスドとなり、既存のオンプレミスのサーバー・デバイスを含めて料金が発生します。料金の詳細は 下記 AWS ドキュメントを参照ください。IoT デバイスの台数が多いシチュエーションでは注意が必要です。また下記 AWS ドキュメントにも記載のとおり AWS Systems Manager にて Session Manager を使用する場合、1,000 台を超えなくともアドバンスドが必要となりますのでこちらも注意が必要です。
まとめ
SORACOM Canal や VPC エンドポイントを利用してAWS Systems Manager で閉域接続できました。現状デフォルトでは SSM Agent が PPP インタフェースの IP アドレスを取得せず自前でビルドが必要なのは盲点でした。単にリモートアクセスだけが必要であるなら SORACOM Napter や SORACOM Gate を利用するのが良いと思いますが、AWS Systems Manager ではより高度なリモートアクセス・運用管理の機能も使用できるため、SSM Agent が対応している OS が動くデバイスでは閉域でもその恩恵を受けられると思います。
― ソラコム峯 (mike)
投稿 閉域網内でのAWS Systems ManagerによるIoT機器のリモートアクセスの構成と注意点 は SORACOM公式ブログ に最初に表示されました。
この連載の記事
-
第397回
デジタル
Make a Global Impact as a Technical Writer at Soracom -
第396回
デジタル
SORACOM LTE-M Button powered by AWSの移行受付を開始、SPSアワード 2023の表彰を発表 takuyaのほぼ週刊ソラコム 04/01-04/14 -
第395回
デジタル
SORACOMの新機能開発の舞台裏 ― お客様の声からリリースまでの道のり -
第394回
デジタル
動画で分かる！SORACOM Lagoon 3への移行の手順 -
第393回
デジタル
ソラカメ運用管理をより簡単に！アクセス権限設定テンプレートのご紹介 -
第392回
デジタル
生成AIによる「ブログの原稿作り」手順やプロンプトを公開 -
第391回
デジタル
クラウド型カメラの実機を見ながら相談できる「ソラカメ デモルーム」 -
第390回
デジタル
SORACOM Lagoon 2 から Lagoon 3 への移行に関する、よくある 9 の質問にお答えします -
第389回
デジタル
スイングバイIPOにて、ソラコム本日上場 -
第388回
デジタル
IoTのセンサーやデバイスの選び方・活かし方とは？ ― 2/29セミナーレポート