リダイレクション機能を利用し 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 を追加してください。
Gate Peer を追加したら、「高度な設定」タブを開きます。「お客様の Gate Peer 一覧」でゲートウェイ IP アドレスに指定する Gate Peer の「デバイスサブネット内 IP アドレス」を確認します。ここでは 10.164.245.34
となっています。
次に、「Junction 設定」タブを開きます。「SORACOM Junction: ミラーリング設定」でトグルスイッチを「ON」に、「ゲートウェイ IP アドレス」で先程確認した IP アドレス、 10.164.245.34
を選択して「リダイレクション設定を保存」をクリックします。
以上で Junction のリダイレクション機能の設定は完了です。
ステップ 3: tcpdump を使用して、経路が変更されていることを確認する
tcpdump を使用して、パケットが転送されていることを確認します。
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 を使用してネットワークへの侵入検知や、パートナーソリューションを組み合わせることでさらに高度なトラフィック処理を行うといったことが自在に可能となります。