サーバーワークスはAWSのプレミアコンサルティングパートナーですが、Cradlepoint社のエリートパートナーでもあります。
http://cradlepoint.co.jp/serverworks-co.,-ltd
今回、Cradlepoint社から、「IBR900」という新しい機器をお借りできたので、そちらの検証をしてみました。
こちらの機器については@ITの記事でも紹介されています。
NetCloudの構成をおさらい
まず、検証前にシンプルなNetCloud構成をおさらいしておきます。
- NetCloudのソフトウェアをNetCloud参加マシンにインストールしています。
- 各マシンがインターネット経由でNetCloudに参加すると、172.86.160.0/20の中からアドレスが割り振られます。
- 各マシンはインターネットに接続さえできれば、同じNetCloud空間にあるマシンと172.86.160.0/20のアドレスで通信ができます。
- 各マシン向けの社内のFirewall設定を調整する必要はありません。NetCloudのセッションは、各マシン -> NetCloud 方向となります。
結果、どこにいても同じNetCloudに参加しているマシンにアクセスできます。楽ちんですね。
さて、一つ問題があります。
- NetCloudのソフトウェアをNetCloud参加マシンにインストールしています。
ソフトウェアを自由にインストールできないマシンってありますよね。
例えば、IoT機器だったり、一般的ではないOSを搭載している業務用機器とかはどうしたらいいでしょうか。
諦めるしかないのでしょうか？
なお、NetCloudのソフトがサポートしているOSはこちらに記載があります。
NetCloud Engine Supported Devices
今回の検証内容
「IBR900」等のNetCloud Engine対応ルーターを使えば、上記の問題を解決することができます。
ソフトウェアをインストールできない機器でもNetCloudに参加可能になります。
こんな構成で検証してみました。
AWS側の構成
- EC2 1台をPublic Networkに設置
- セキュリティグループはデフォルトのまま（InboundはSSHのみ開放。Outboundは全開放）
- 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ポートもあるので、有線で既存ネットワークに接続するのも問題ありません。
Macの構成
特別な設定は不要です。
IBR900にLANポートとMacを有線で接続し、DHCPでアドレスが割り当てられます。
テストの都合上Macを使っていますが、ここは一般的なTCP/IP通信ができる機器なら何でもいいはずです。
このMacを皆さまの利用したいIoT機器などに置き換えて想像していただければと思います。
NetCloud Manager で登録状況を確認する
NetCloudには、NCM (NetCloud Manager)というコントロールパネルがあり、そちらで状態確認や設定ができます。
以下のように機器が登録され、それぞれにホスト名とIPアドレスが割り振られています。
EC2 の登録状況
IBR900 の登録状況
Mac (IBR900の配下の機器) の登録状況
検証結果
上記の構成で実際にどのような動きをするのか見ていきます。
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年入社 / 地味な内容を丁寧に書きたい
