フォーム読み込み中
皆さんこんにちは。IoT ソリューションアーキテクトのTakamasaです。
低容量IoT回線「1NCE」で標準で使用できるOpenVPNを使った冗長構成について、説明していきます。
まずはおさらいですが、1NCE(ワンス) というIoT回線の特徴を簡単にまとめてみます。
SIMカード1枚からオンラインで購入可能
日本国内に加えて、170以上の国と地域において追加料金なしでローミングサービスを利用可能
SIMカードに加えて、ウェブ上の回線管理ツール(CMP)や、お客さまのシステムとのデータ連携を可能にするAPI、安全にデータを伝送するOpen VPNなどの機能を追加料金なしで利用可能
eSIMやIPSec(各拠点のLANを相互接続する高セキュリティのネットワーク)、Transit Gateway(AWS VPC同士を接続)などの機能を、有償の追加オプションとして提供
一番の特徴は、IoT回線でよくありがちな基本料金+従量課金ということではなく、一括で10年間前払いするという部分がとても特徴的ですね。
また今回使ってみるSIM管理プラットフォームについても、2,200円(税込)の中で使用できるということなので、気軽にIoTをプロトタイピングしてみるといった使い方でもできそうです。
なお、1NCE(ワンス)SIMカードでは法人ユーザーであれば、どなたでも1枚からWebで購入が可能です。
1NCEのSIM回線プラットフォーム自体には、REST APIや、IMEIロック、SMS送信、回線無効化、追加チャージなど、回線に関わる操作が一元的に管理できるものなっています。
OpenVPNは、仮想プライベートネットワーク(VPN)のソリューションの1つであり、主な特徴としては、オープンソースのソフトウェアであり、現在も世界中で利用されているサービスの1つです。
オープンソースというのは、インターネット上でソースが公開されているということで、誰でもコードをレビューしたり、コード自身をカスタマイズできるので、セキュリティや信頼性が高いと言えます。但し、逆に言えば管理者という人はいないので、カスタマイズにより動作しなくなる、不安定になるといったことは自己責任になります。
因みにコード自体はGitHubで公開されています。
ただ基本的にOpenVPNを使う場合には、色々なライブラリが配布されていますので、難しく考えずにライブラリをインストールして、設定ファイルをいれれば接続自体は完成します。
また1NCEのOpenVPNの制限としては、以下のポイントを抑えておいてください。
そしてここからが今回の主題になります。
OpenVPNは無償で使えたり、自分で自由にカスタマイズできたり、一時接続にも使えたりと何かと便利な接続方法である一方で、シンプルに使ってしまうと万が一サーバ断が発生したときに対処できなくなる恐れがあります。
また1NCEのOpenVPNの制限として、1アカウントと1接続しか接続を維持できないという制限もあり、そのため冗長性を確保しようとする際のハードルの1つとなっています。
1NCE VPNサービスは、1つの(サブ)組織につき1つのアクティブなVPNクライアント接続を同時にサポートします(下の図を参照)。
複数のクライアントが同時に接続しようとする場合、クライアント間の一貫性のないデータ接続とランダムな切断が発生します。1NCEネットワークへの複数の接続を確立するには、IPSecサービスを参照するか、追加のサブ組織を作成してください。各(サブ)組織は独自のアクセスデータを受け取ります。
1NCE Developper Hub - VPNサービスの仕様と制限事項
ここからが実際の解決策になります。
高信頼性を確保するための手段としては、ロードバランサーを入れてラウンドロビン方式で分散させる方式(1:N)か、もしくはメイン&バックアップ構成にさせて二重化する方式(1:1)と大きく2つあると思いますが、今回は1NCEのOpenVPNが同時に2本張ることができないという仕様なので、ラウンドロビン方式では実現できそうにないので、メインバックアップ方式で実装していきたいと思います。
一方で、メインバックアップ方式を実現する技術としては今回VRRP(Virtual Router Redundancy Protocol)を使っていきたいと思います。
元々は2つのルーターの間で仮想IP(VIP)を保持させて、外部からは常に1つのIPアドレスしか見えないようにするという技術ですが、1NCEネットワークとしてはSIMからの通信先に関してはOpenVPN内にアサインされるIPアドレスしか見えないようになっているので、基本はVIP=VPN IPになるのでここだけ工夫(手抜き)ができます。
今回実装する構成は以下になります。
因みにVIPを使えない理由としては、AWSの場合はAvailability Zoneを別けないと冗長の意味がないので、別けるとこととすると、結果的にサブネットが分かれることになるのでどうしても同じIPアドレスになることができないということがあります。
加えて前述のように1NCEからの通信はVPN IPアドレス(上の図では10.AA.BB.CC)になるので、あまりVIPを持つ意味はないということがあります。
また今回はホットスタンドバイ構成にしているので、基本的にはメインが止まったことを検知したら即時(2秒以内)にスタンドバイに切り替わります。但しこの方法だと常にスタンドバイ側を起動状態にしておかないといけないので、もし数分間のダウンが許容できるのであれば、コールドスタンドバイの構成にすることも検討は可能です。
今回試験で作成したサーバ側のソフトウェア要件は以下になります。
OpenVPN 2.6.9
Python 3.12.3
特にこれじゃないと動かないわけではないですが、OpenVPNはver3は1NCEがサポートしていないので、必ずver2以下にしてください。
またPythonに関しても、versionによってライブラリが使えるかわからないので注意してください。
先ずは1NCEポータルサイトにアクセスし、閉域接続させたいアカウントでログインしてください。
設定>OpenVPNまで進めば、ファイルがダウンロードできるようになります。
この.confファイルと.txtファイルをダウンロードし、一先ず自分のPCに保存しておいてください。
因みに設定ファイル(.conf)の中を見てみるといくつかの設定項目があるかと思いますが、基本は何も変更せずにそのまま利用することが可能です。
但し、設定自体はカスタマイズ可能な項目もあるので、以下を参照して変更したいものがあればこれを参照ください。
1NCE Developer Hub - VPN設定ファイル
次にOpenVPN Clientを構築していきます。
今回は、AWS上に構築していきますが、AWS側の設定はここでは省きますが、必要なリソースやキーペア、セキュリティグループなどは適切に設定してください。
先ずはOpenVPNをインストールしていきたいと思いますが、AWSのUbuntuに関しては基本的にデフォルトでインストールされています。
$ openvpn –version
もしインストールされていないようであれば、以下コマンドからOpenVPNをインストールしていきましょう。
$ apt install openvpn
あとは1NCEポータルからダウンロードした、.txtファイルを以下のフォルダ直下においてください。
/etc/openvpn
また.confファイルについては接続先情報になるので、以下のフォルダの中に、設定ファイルを保存しておきます。
$ mkdir /etc/openvpn/client
その状態で、以下コマンドを実行させてOpenVPNのサービスをスタートさせ、その後サービスを再起動時でも動作するようにしておきます。
$ sudo systemctl start openvpn-client@ap-northeast-1-client
$ sudo systemctl enable openvpn-client@ap-northeast-1-client
これでOpenVPN Client自体は完成となります。
次はVRRPを導入して、サーバ同士を同期・監視させます。先ずはkeepalivedのライブラリをインストールしていきます。
$ sudo apt install keepalived
次にkeepalivedの設定ファイルを作っていきます。
設定ファイルを見てわかるかもしれませんが、VIPの設定部分だけは使わないので省いています。
$ sudo vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL_A # スタンドバイ側では”LVS_DEVEL_B”
}
vrrp_script chk_services {
script "pidof openvpn"
interval 2
fall 3
rise 2
}
vrrp_instance VI_1 {
state MASTER # スタンドバイ側では”BACKUP”
interface enX0 # サーバのインターフェース名に合わせる
virtual_router_id 51
priority 100 # スタンドバイ側では”90” <- 100より小さい数
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
unicast_peer {
10.xx.xx.xx # スタンドバイのIPアドレス、スタンドバイ側ではメインのIPアドレス
}
track_script {
chk_services
}
notify_master "/etc/keepalived/scripts/start_services.sh"
notify_backup "/etc/keepalived/scripts/stop_services.sh"
}
基本的に2台構成にすると思いますので、サーバAに入れる構成と、サーバBには別々の構成ファイルを入れておきます。
上記はメインサーバの設定ファイルですが、コメント部分についてはスタンドバイ側で変更してください。
またサーバが切り替わった際にサービスを止める or 再開させるスクリプトも同じように仕込んでおきます。
通常どちらがマスターとするかは、VIPなどを用いればできると思うのですが、今回はVIPを使わないので明示的に自分がMASTERであることを示すようなファイルを仕込んでおきます。
こちらが起動スクリプトです。
$ sudo vim /etc/keepalived/scripts/start_services.sh
$ cat start_services.sh
#!/bin/bash
# MASTER状態を示すファイルを作成
echo "true" > /tmp/keepalived_master_state
# サービスの起動
sudo systemctl start openvpn-client@ap-northeast-1-client
そして以下が停止スクリプトになります。
$ sudo vim /etc/keepalived/scripts/stop_services.sh
$ cat stop_services.sh
#!/bin/bash
# MASTER状態を示すファイルを削除
rm -f /tmp/keepalived_master_state
# サービスの停止
sudo systemctl stop openvpn-client@ap-northeast-1-client
また実行権限も付与しておくことを忘れないようにしましょう
$ sudo chmod +x /etc/keepalived/scripts/start_services.sh $ sudo chmod +x /etc/keepalived/scripts/stop_services.sh
因みにサーバが切り替わった際の通知スクリプトについても作成することはできますが、今回はシンプルにしているため作成していません。
上記の設定ファイルとスクリプトが作成できたら、以下コマンドで同様にサービス化させておきます。
$ sudo systemctl start keepalivedf
$ sudo systemctl enable keepalived
ここからは、スタンドバイ側のサーバを作成していきます。
ただ基本的にメインサーバと全く同じなので、折角なので楽して作っていきたいと思います。
サーバの複製に関しては、AWSのAMIイメージを複製して、AMIイメージから新規にサーバを作っていきたいと思います。
先ずは、AWSのマネジメントコンソールにログインして、EC2のタブを開き、そして複製したいメインサーバをクリックし、アクション>イメージを複製していきます。
AMIイメージが作成完了したら、AMIイメージからEC2をアップしていきましょう。
念のためですが、メインサーバとスタンドバイサーバの両方に、Elastic IPアドレスと、IGWへのルーティングはテーブルにしっかりと追加しておきましょう。
スタンドバイ側は、基本的にメインサーバの複製になっているので、新規にソフトを入れる必要はありませんが、keepalivedの設定ファイルだけはスタンドバイ用に修正しておきます。
$ sudo vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL_B
}
vrrp_script chk_services {
script "pidof openvpn"
interval 2
fall 3
rise 2
}
vrrp_instance VI_1 {
state BACKUP
interface enX0 # サーバのインターフェース名に合わせる
virtual_router_id 51
priority 90 # メインのPriorityよりも低くしておく
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
unicast_peer {
10.xx.xx.yy # メインサーバのIPアドレスに変える
}
track_script {
chk_services
}
notify_master "/etc/keepalived/scripts/start_services.sh"
notify_backup "/etc/keepalived/scripts/stop_services.sh"
}
上記の設定ファイルとスクリプトが作成できたら、以下コマンドで同様にサービス化させておきます。
$ sudo systemctl start keepalived
$ sudo systemctl enable keepalived
ここまでできたら、冗長構成としては完成になります。
構成としてはこんな感じになっているはずです。
現在の設定では、メインサーバが基本的に稼働しており、メインサーバのopenvpnサービスが止まったら、もしくはサーバ自体が止まっていることを検知した場合に、スタンドバイサーバに切り替わるという処理が走るようになっています。
初期設定では、2秒おきに互いにサーバの状態をチェックし、異常を検知した場合にメインサーバ側で起動スクリプトが走ります。
ということで、試しに1NCE SIMが刺さったデバイスから、OpenVPNのClient IPにPingを打ち続けます。
この状態でメインサーバをブチっと止めてみます。
一瞬Pingが止まりましたが、7秒後に復旧しました。
その後何回か試してみましたが、凡そ10秒以内程度には復旧しているので、これであれば十分に可用性はとれていると言えるんじゃないでしょうか?
またバックアップ側のサーバログを確認してみてもしっかりとマスターに格上げされていることが確認できます。またその後マスター側を復帰させると、またバックアップに律儀に戻っていきます。
ちゃんと冗長性が保たれていることが確認できました。
今回はOpenVPNを使って、冗長構成を組み上げてみました。
そもそもOpenVPNって、ピアツーピアにしか使えないんじゃないかと思っている人もいたかもしれませんが、今回の構成であればコストを抑えて、比較的自由度高くネットワークを構築できるということがわかりました。
EC2 x 2台の価格は、価格を抑えて使えば年間で300ドル未満だと思うので、Transit GWやIPsecを利用するよりは遥かに値段を抑えて利用することができます。また今回はホットスタンドバイの構成でしたが、コールドスタンドバイの構成で良いのであれば、更に値段は抑えられるかと思います。
これから1NCEを使って、IoTシステムを構築したいと思っている方は是非ソフトバンクもしくは1NCEまでご相談ください。
1NCE(ワンス)SIMカードでは法人ユーザーであれば、どなたでも1枚からWebで購入が可能で、今回紹介した1NCE SIM管理プラットフォームの機能は、アカウントユーザーであればであれば誰でも無料で試すことができますので、先ずは是非触ってみてください。
1NCE IoTフラットレートはIoTコネクティビティに特化した通信接続サービスです。
▶ 「低容量SIM」ユースケース 資料ダウンロード
条件に該当するページがございません