Cradlepoint NetCloud Engine(旧Pertino)対応ルーターを検証してみた

記事タイトルとURLをコピーする

サーバーワークスはAWSのプレミアコンサルティングパートナーですが、Cradlepoint社のエリートパートナーでもあります。

http://cradlepoint.co.jp/serverworks-co.,-ltd

今回、Cradlepoint社から、「IBR900」という新しい機器をお借りできたので、そちらの検証をしてみました。

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711172726.jpg

こちらの機器については@ITの記事でも紹介されています。

www.atmarkit.co.jp

NetCloudの構成をおさらい

まず、検証前にシンプルなNetCloud構成をおさらいしておきます。

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173106.png

  1. NetCloudのソフトウェアをNetCloud参加マシンにインストールしています。
  2. 各マシンがインターネット経由でNetCloudに参加すると、172.86.160.0/20の中からアドレスが割り振られます。
  3. 各マシンはインターネットに接続さえできれば、同じNetCloud空間にあるマシンと172.86.160.0/20のアドレスで通信ができます。
  4. 各マシン向けの社内のFirewall設定を調整する必要はありません。NetCloudのセッションは、各マシン -> NetCloud 方向となります。

結果、どこにいても同じNetCloudに参加しているマシンにアクセスできます。楽ちんですね。

さて、一つ問題があります。

  1. NetCloudのソフトウェアをNetCloud参加マシンにインストールしています。

ソフトウェアを自由にインストールできないマシンってありますよね。
例えば、IoT機器だったり、一般的ではないOSを搭載している業務用機器とかはどうしたらいいでしょうか。
諦めるしかないのでしょうか?

なお、NetCloudのソフトがサポートしているOSはこちらに記載があります。
NetCloud Engine Supported Devices

今回の検証内容

「IBR900」等のNetCloud Engine対応ルーターを使えば、上記の問題を解決することができます。
ソフトウェアをインストールできない機器でもNetCloudに参加可能になります。

こんな構成で検証してみました。

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173109.png

AWS側の構成

  1. EC2 1台をPublic Networkに設置
  2. セキュリティグループはデフォルトのまま(InboundはSSHのみ開放。Outboundは全開放)
  3. NetCloudのソフトウェアをインストール・起動させ、NetCloudにログイン

上手くいくと、下記のようにpertino0という仮想インターフェースが作成されるのが確認できます。
今回は172.86.160.7というアドレスが割り振られていますね。

[root@ip-10-10-0-181 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 06:6D:4C:81:53:26
          inet addr:10.10.0.181  Bcast:10.10.0.255  Mask:255.255.255.0
          inet6 addr: fe80::46d:4cff:fe81:5326/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37759 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9352638 (8.9 MiB)  TX bytes:4351907 (4.1 MiB)
          Interrupt:247

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:720 (720.0 b)  TX bytes:720 (720.0 b)

<strong>pertino0</strong>  Link encap:Ethernet  HWaddr DA:68:28:C1:CC:8D
          inet addr:<strong>172.86.160.7</strong>  Bcast:172.86.175.255  Mask:255.255.240.0
          inet6 addr: fe80::d868:28ff:fec1:cc8d/64 Scope:Link
          inet6 addr: 2001:470:813b::65e5:0:602/48 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
          RX packets:27337 errors:0 dropped:0 overruns:0 frame:0
          TX packets:412 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:2465493 (2.3 MiB)  TX bytes:68050 (66.4 KiB)

IBR900の構成

IBR900には2枚までSIMカードを差すことができます。
今回はインターネットへの接続は、SORACOM回線で行いました。
SORACOMのSIMカードを使う場合にはAPN設定が必要です。
なお、物理WANポートもあるので、有線で既存ネットワークに接続するのも問題ありません。

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173103.png

Macの構成

特別な設定は不要です。
IBR900にLANポートとMacを有線で接続し、DHCPでアドレスが割り当てられます。
テストの都合上Macを使っていますが、ここは一般的なTCP/IP通信ができる機器なら何でもいいはずです。
このMacを皆さまの利用したいIoT機器などに置き換えて想像していただければと思います。

NetCloud Manager で登録状況を確認する

NetCloudには、NCM (NetCloud Manager)というコントロールパネルがあり、そちらで状態確認や設定ができます。
以下のように機器が登録され、それぞれにホスト名とIPアドレスが割り振られています。

EC2 の登録状況

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173041.png

IBR900 の登録状況

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173045.png

Mac (IBR900の配下の機器) の登録状況

https://cdn-ak.f.st-hatena.com/images/fotolife/s/serverworks/20200711/20200711173049.png

検証結果

上記の構成で実際にどのような動きをするのか見ていきます。

Mac -> EC2 ping OK

~ $ ping 172.86.160.7
PING 172.86.160.7 (172.86.160.7): 56 data bytes
64 bytes from 172.86.160.7: icmp_seq=0 ttl=63 time=227.089 ms
64 bytes from 172.86.160.7: icmp_seq=1 ttl=63 time=203.947 ms
64 bytes from 172.86.160.7: icmp_seq=2 ttl=63 time=164.109 ms
64 bytes from 172.86.160.7: icmp_seq=3 ttl=63 time=170.345 ms
64 bytes from 172.86.160.7: icmp_seq=4 ttl=63 time=174.216 ms
64 bytes from 172.86.160.7: icmp_seq=5 ttl=63 time=173.909 ms
64 bytes from 172.86.160.7: icmp_seq=6 ttl=63 time=203.297 ms
^C
--- 172.86.160.7 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 164.109/188.130/227.089/21.670 ms

上記見ると遅延が大きいですが、何度か試したところ50msくらいの時もありました。
ま遅延の原因としてはLTE回線によるものが大きいと推測しています。 (NetCloudをインストールしたEC2間で測定したところ、5msくらいだったので。)

Mac -> EC2 ssh OK

~ $ ssh -i root@172.86.160.7

[root@ip-10-10-0-181 ~]# netstat -lanput
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      805/sshd            
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      881/master          
tcp        0      0 127.0.0.1:47197             0.0.0.0:*                   LISTEN      1188/./pGateway     
tcp        0    261 10.10.0.181:50849           54.178.57.115:443           ESTABLISHED 1188/./pGateway     
tcp       32      0 10.10.0.181:42655           23.21.217.50:443            CLOSE_WAIT  1188/./pGateway     
<strong>tcp        0    128 172.86.160.7:22             172.86.160.9:49748          ESTABLISHED 6820/sshd  </strong>         
tcp        0      0 :::22                       :::*                        LISTEN      805/sshd            
udp        0      0 0.0.0.0:52109               0.0.0.0:*                               1188/./pGateway     
udp        0      0 0.0.0.0:46632               0.0.0.0:*                               1188/./pGateway     
udp        0      0 0.0.0.0:68                  0.0.0.0:*                               5187/dhclient       
udp        0      0 0.0.0.0:68                  0.0.0.0:*                               691/dhclient 

172.86.160.0/20のアドレス内でセッションが張られています。

EC2 -> Mac(リアルアドレス) ping NG

[root@ip-10-10-0-181 ~]# ping 192.168.0.134
PING 192.168.0.134 (192.168.0.134) 56(84) bytes of data.
^C
--- 192.168.0.134 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4684ms

Macのリアルアドレスとは通信できません。
やはりNetCloudアドレス(172.86.160.0/20) を使う必要があります。

EC2 -> Mac(NetCloudアドレス) ping OK

[root@ip-10-10-0-181 ~]# ping 172.86.160.9
PING 172.86.160.9 (172.86.160.9) 56(84) bytes of data.
64 bytes from 172.86.160.9: icmp_seq=1 ttl=63 time=196 ms
64 bytes from 172.86.160.9: icmp_seq=2 ttl=63 time=154 ms
64 bytes from 172.86.160.9: icmp_seq=3 ttl=63 time=152 ms
64 bytes from 172.86.160.9: icmp_seq=4 ttl=63 time=162 ms
64 bytes from 172.86.160.9: icmp_seq=5 ttl=63 time=150 ms
64 bytes from 172.86.160.9: icmp_seq=6 ttl=63 time=169 ms
64 bytes from 172.86.160.9: icmp_seq=7 ttl=63 time=178 ms
^C
--- 172.86.160.9 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6933ms
rtt min/avg/max/mdev = 150.915/166.367/196.089/15.221 ms

Macに割り当てられたNetCloudアドレスとは通信できます。

まとめ

今回の検証で下記を確認できました。

  • NetCloud参加マシン同士の通信は172.86.160.0/20で行われる。
  • IBR900などの配下にいるだけで、直接NetCloudに参加していないマシンにも172.86.160.0/20が割り当てられる。

良くも悪くも普通に通信できました。
ネットワークに関しては普通に使えるというのが大切ですね。

クラウドとネットワークの問題でお困りの方はサーバーワークスまでご相談いただければと思います。

余談

今回ロケーション的にはオフィスで検証したのですが、SORACOM使用のため社内ネットワークに全く接続せずに検証ができました。
企業によっては、社内ネットワークにイレギュラーな機器を接続する時は社内調整が必要になることもあるかと思います。
3G/LTE回線などをルータに差して使うというのも一つのソリューションですね。

渡辺 信秀(記事一覧)

2017年入社。趣味は言語学習。