リダイレクション機能を利用し VPG を通過するパケットの経路を変更する

当ガイドでは、SORACOM Junction (以下、Junction)のリダイレクション機能を利用し、VPG を通過するパケットを VPC の EC2 インスタンスを経由するように経路を変更して転送する操作を実施してみます。

インスペクション

ステップ 1: Gate を使用して VPG と EC2 インスタンス間に仮想 L2 ネットワークを構築する

Junction のリダイレクション機能は IP ルーティングにおける Next Hop を変更することでお客様が指定したサーバを経由した通信を実現することから、お客様のサーバと VPG の間で L2 ネットワークを構築する必要があります。これを簡単に実現する方法として、SORACOM Gate によって仮想 L2 ネットワークで接続された Gate Peer を活用することが可能です。すなわち、SORACOM Gate で設定した Gate Peer を VPG の Next Hop となるように VPG を通過するパケットがルーティングされます。

まず、 Getting Started: クラウドからデバイスへアクセスするに従って SORACOM Gate により Gate Peer を追加し、Gate Peer と VPG との間で仮想 L2 ネットワークを構築してください。

設定が終ったら以下の項目が正常に設定されていることを改めて確認してください。

Canal によるピアリング接続が受諾されており、VPC のルートテーブルに 100.64.0.0/10 に対するルールが存在する
VPG にグループが設定されており、SIM がグループに所属している
Gate Peer からデバイスに接続できる
Gate Peer のパケット転送が有効になっている

ここでは例として、VPC ピアリングした VPC の CIDR ブロックは 192.168.255.0/24 であるとします。

まず、Gate Peer で iptables を使用して IP マスカレードのルールを追加します。

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

次に、Gate Peer のパケット転送が有効になっていることを以下のコマンドで確認します。

$ 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

以下の項目を確認してください。

sysctl で net.ipv4.ip_forward の値が 1 になってパケット転送が有効になっている
iptables で NAT テーブルの POSTROUTING chain に eth0 に対する IP マスカレードのルールが追加されている

ステップ 2: Junction のリダイレクション機能を設定する

クラウドからデバイスへアクセスするで作成した VPG の設定画面を開きます。「Junction 設定」タブを開きます。

正常に Gate Peer が設定されて いない 場合、以下のように表示されますので、 Getting Started: クラウドからデバイスへアクセスするを参考にして、Gate Peer を追加してください。

Redirection

Gate Peer を追加したら、「高度な設定」タブを開きます。「お客様の Gate Peer 一覧」でゲートウェイ IP アドレスに指定する Gate Peer の「デバイスサブネット内 IP アドレス」を確認します。ここでは 10.164.245.34 となっています。

Redirection

次に、「Junction 設定」タブを開きます。「SORACOM Junction: ミラーリング設定」でトグルスイッチを「ON」に、「ゲートウェイ IP アドレス」で先程確認した IP アドレス、 10.164.245.34 を選択して「リダイレクション設定を保存」をクリックします。

Redirection

以上で Junction のリダイレクション機能の設定は完了です。

ステップ 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 パケットをブロックする

ここで、リダイレクション先でトラフィックをコントロールする一つの例として、実際にパケットをフィルタリングできることを確認するために iptable のルールを追加して、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 OUTPUT -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 の対象ホストからの反応が返ってこない(対象ホストへ ICM パケットが届いいていない)ことが確認できたら成功です。

最後に、作成した iptables のルールを削除しましょう。まず、作成したルールの chain 中のルール番号を取得します。 OUTPUT chain のセクションを参照して、ICMP パケットを drop しているルールのルール番号を確認します。

$ sudo iptables -L --line-numbers
...
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ufw-before-logging-output  all  --  anywhere             anywhere
2    ufw-before-output  all  --  anywhere             anywhere
3    ufw-after-output  all  --  anywhere             anywhere
4    ufw-after-logging-output  all  --  anywhere             anywhere
5    ufw-reject-output  all  --  anywhere             anywhere
6    ufw-track-output  all  --  anywhere             anywhere
7    DROP       icmp --  anywhere             anywhere             icmp echo-request
...

上記例でルール番号は 7 となっているので、以下のコマンドでルールを削除します。

$ sudo iptables -D OUTPUT 7

上記を実行後、再度冒頭と同じように ping コマンドを実行してみてください。ルールを削除したことで再度疎通するようになったことを確認できます。

以上、リダイレクション先でトラフィックをコントロールする例として、iptables を使ったパケットフィルタリング実施してみました。SORACOM Junction のリダイレクション機能を応用することで用いることで、パケットのフィルタリングだけでなく、tc を使った帯域制御や、Snort を使用してネットワークへの侵入検知や、パートナーソリューションを組み合わせることでさらに高度なトラフィック処理を行うといったことが自在に可能となります。