リダイレクション機能を利用し VPG を通過するパケットの経路を変更する
Junction のリダイレクション機能を利用して、VPG を通過するパケットを Amazon VPC の EC2 インスタンスを経由するように経路を変更して転送します。
ステップ 1: Gate を使用して VPG と EC2 インスタンス間に仮想 L2 ネットワークを構築する
Junction のリダイレクション機能は IP ルーティングにおける Next Hop を変更することでお客様が指定したサーバを経由した通信を実現することから、お客様のサーバと VPG の間で L2 ネットワークを構築する必要があります。これを簡単に実現する方法として、Gate によって仮想 L2 ネットワークで接続された Gate Peer を活用できます。すなわち、Gate で設定した Gate Peer を VPG の Next Hop となるように VPG を通過するパケットがルーティングされます。
クラウドからデバイスへアクセスする (SORACOM Gate C2D) に従って SORACOM Gate の Gate Peer を追加し、Gate Peer と VPG との間で仮想 L2 ネットワークを構築します。
以下の項目が正常に設定されていることを改めて確認します。
- Canal によるピアリング接続が受諾されており、Amazon VPC のルートテーブルに
100.64.0.0/10に対するルールが存在する - VPG にグループが設定されており、IoT SIM がグループに所属している
- Gate Peer からデバイスに接続できる
- Gate Peer のパケット転送が有効になっている
- Canal によるピアリング接続が受諾されており、Amazon VPC のルートテーブルに
Gate Peer で
/etc/sysctl.confに以下の内容を追加します。net.ipv4.ip_forward=1すでに以下のように記載されている場合は、上のように書き換えてください。
#net.ipv4.ip_forward=1/etc/sysctl.conf/の変更を反映します。$ sudo sysctl -pパケット転送が有効になっていることを確認します。
$ sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1
送信元 IP アドレスを Gate Peer の IP アドレスに変更する場合
デバイスからの通信について、送信元 IP アドレスを Gate Peer のアドレスに変更する場合は、さらに以下のとおりに設定してください。
Gate Peer で iptables を使用して IP マスカレードのルールを追加します。
$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEGate Peer のパケット転送が有効になっていることを確認します。
具体的には、以下のコマンドで NAT テーブルの
POSTROUTINGchain に eth0 に対する IP マスカレードのルールが追加されていることを確認します。$ sudo iptables -t nat -L -v Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- any vxlan0 anywhere anywhere 0 0 MASQUERADE all -- any eth0 anywhere anywhere
ステップ 2: Junction のリダイレクション機能を設定する
クラウドからデバイスへアクセスする (SORACOM Gate C2D) で作成した VPG の VPG 設定画面を表示します。
VPG 設定画面を表示する操作について詳しくは、VPG の設定を変更する を参照してください。
をクリックし、 の の設定を確認します。
- (*) 画像は、Amazon VPC ピアリング接続した Amazon VPC の CIDR ブロックが
192.168.255.0/24の場合の例です。
Gate Peer が設定されていない場合は、お客様の Gate Peer を追加してください
お客様の Gate Peer を追加する方法については、Gate Peer を VPG に登録する を参照してください。
- (*) 画像は、Amazon VPC ピアリング接続した Amazon VPC の CIDR ブロックが
をクリックし、 の各項目を設定します。
項目 説明 スイッチ ON にします。リダイレクション機能を無効にする場合は、OFF にします。 手順 1 で確認した Gate Peer の「デバイスサブネット内 IP アドレス」を選択します。例: 10.164.245.34任意の文字列を入力できます。 
をクリックします。
SORACOM API の場合
- SORACOM API を利用するには、API キーと API トークンが必要です。詳しくは、API キーと API トークンの取り扱いについて を参照してください。
{vpg_id}は、VirtualPrivateGateway:listVirtualPrivateGateways APIで取得できます。
VirtualPrivateGateway:setRedirectionConfiguration API を使用します。
$ curl -v -X POST https://api.soracom.io/v1/virtual_private_gateways/{vpg_id}/junction/set_redirection \
-H "X-Soracom-API-Key: $X_SORACOM_API_KEY" \
-H "X-Soracom-Token: $X_SORACOM_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"enabled": true,
"gateway": "{Gate PeerのIPアドレス}",
"description": "{概要}"
}'
ステップ 3: tcpdump を使用して、経路が変更されていることを確認する
tcpdump を使用して、パケットが転送されていることを確認します。
- 設定した VPG が指定されたグループに所属する IoT SIM が挿入されたデバイスで通信が可能であることを確認してください。通信が可能であれば設定が正しく完了し、VPG を通過するトラフィックが EC2 インスタンスを経由するように経路を変更して転送されています。
- もし通信ができない場合は設定に誤りがあるので、再度 Gate の設定および Junction のリダイレクション機能の設定を確認してください。
- また、Gate Peer がインターネットへ接続可能な環境にない場合、設定した VPG と同じグループに所属する SIM が挿入されたデバイスもインターネットへ接続できないことに注意してください。
Gate Peer である EC2 インスタンスへ SSH でログインします。<public-ip> を Gate Peer のパブリック IP アドレスに置き換えてください。ここでは EC2 インスタンスが Amazon Linux として ec2-user でログインしていますが、Ubuntu の場合は ubuntu など、適宜各自の環境に合わせてユーザー名を変更してください。また、秘密鍵ファイルも各自の環境に合わせて適宜変更してください。
$ ssh -X -i "xxx-dev01.pem" ec2-user@<public-ip>
以下のように tcpdump を使用して経路を変更されたパケットが VXLAN でカプセル化されて転送されているかを確認します。VXLAN でカプセル化されて eth0 へ入ってきたパケットが再び eth0 から出ていく様子が確認できれば成功です。以下の例ではデフォルトで tcpdump がインストールされていますが、お使いの EC2 インスタンスの Linux ディストリビューションで tcpdump がインストールされているか確認し、もしされていない場合にはパッケーマネージャでインストールしてください。
ec2-user@ip-172-16-1-92:~$ sudo tcpdump -vvv -i eth0 not port ssh
sudo: unable to resolve host ip-172-16-1-92
...
(オプション) iptables を使用して、ICMP パケットをブロックする
ここで、リダイレクション先でトラフィックをコントロールする一つの例として、実際にパケットをフィルタリングできることを確認するために iptables のルールを追加して、VPG と同じグループに所属する SIM が挿入されたデバイスからの ping コマンドで生成される ICMP パケットをブロックし、いわゆる"ping が通らない"状態にできることを確認してみます。
まず、VPG と同じグループに所属する SIM が挿入されたデバイスから ping コマンドで ICMP Echo Requesst に応答するホスト (下記の例では soracom.io) へ ICMP パケットを送信します。ping コマンドの送信先は任意のホストを指定できます。
$ ping -c 3 soracom.io
PING soracom.io (52.222.205.45) 56(84) bytes of data.
64 bytes from 52.222.205.45: icmp_seq=1 ttl=247 time=4.52 ms
64 bytes from 52.222.205.45: icmp_seq=2 ttl=247 time=4.61 ms
64 bytes from 52.222.205.45: icmp_seq=3 ttl=247 time=4.51 ms
--- soracom.io ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.511/4.550/4.618/0.048 ms
次に、Gate Peer 上で iptables でルールを追加し ICMP の Echo Request が Gate Peer より先に転送されないようにします。
$ sudo iptables -A FORWARD -p icmp --icmp-type echo-request -j DROP
一時的な設定です
この設定は sudo service iptables save や iptables-save を使用しない限り永続的に反映されません。Gate Peer を再起動した際などには、設定が消失します。
次に VPG と同じグループに所属する SIM が挿入されたデバイスから ping コマンドで soracom.io へ ICMP パケットを送信します。ping コマンドの送信先は Gate Peer 以降に通過する任意のホストを指定できます。
$ ping -c 3 soracom.io
...
ここで ping の対象ホストからの反応が返ってこない (対象ホストへ ICMP パケットが届いいていない) ことが確認できたら成功です。
最後に、作成した iptables のルールを削除しましょう。まず、作成したルールの chain 中のルール番号を取得します。FORWARD chain のセクションを参照して、ICMP パケットを drop しているルールのルール番号を確認します。
$ sudo iptables -L --line-numbers
...
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 DROP icmp -- anywhere anywhere icmp echo-request
...
上記例でルール番号は 1 となっているので、以下のコマンドでルールを削除します。
$ sudo iptables -D FORWARD 1
上記を実行後、再度冒頭と同じように ping コマンドを実行してみてください。ルールを削除したことで再度疎通するようになったことを確認できます。
以上、リダイレクション先でトラフィックをコントロールする例として、iptables を使ったパケットフィルタリング実施してみました。SORACOM Junction のリダイレクション機能を応用することで用いることで、パケットのフィルタリングだけでなく、tc を使った帯域制御や、Snort を使用してネットワークへの侵入検知や、パートナーソリューションを組み合わせることでさらに高度なトラフィック処理を行うといったことが自在に可能となります。