VPC ルーティングを使用したネットワーク仮想化 (NFV)

記事をシェアする:

この投稿は、2021年3月22日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。

VPCルーティングを使用したSquid NFVのデモをご紹介します。

仮想プライベートクラウド（VPC）（英語）は、他のすべてのパブリッククラウドのテナントから論理的に分離された仮想ネットワークを定義し、かつ制御する機能を提供し、パブリッククラウド上にプライベートで安全な場所を作り出します。

VPCルーティングは、ネットワークフローをより細かく制御することができ、サードパーティによるルーティング、ファイアウォール、ローカル/グローバルロードバランシング、Webアプリケーションファイアウォールなどの高度なネットワークサービスのためのネットワーク仮想化（NFV）をサポートするために使用することができます。

この記事では、Squid NFVのデモを行います。Palo AltoやF5のようなファイアウォールインスタンスも同様に構成できます。Squidは、HTTP、HTTPS、FTPなどをサポートするWeb用のキャッシングプロキシです。頻繁に要求されるウェブページをキャッシングして再利用することで、帯域幅を削減し、応答時間を改善します。* Squidのサイトより引用

ホストインスタンスは、インターネットのウェブサイトから読み取ります。ホストのサブネットからインターネット行きのトラフィックは、ルーティング・テーブルと経路によってプロキシインスタンスに送られます。プロキシインスタンス上のSquid NFVは、Webサイトに接続し、ホストとWebサイトの間の仲介役として機能します。

上の図では、Webサイトはneverssl.comです。Squidプロキシはneverssl.comになりすまします（aka spoof）。プロキシは会話の中で検出不可能な仲介者となるため、ホスト上の既存のアプリケーションがSquidの機能を利用するためにコードを変更する必要はありません。

コンソールをクリックして、VPC、サブネット、ルートテーブル、ルートテーブルの経路、インスタンスなどを作成することができます。この投稿ではTerraform（英語）を使用します。起動から実行まで数分でできます。

ツールの前提条件

プロビジョニングの手順はCLIで行います。時間をかけてプロビジョニングのステップを CI/CD パイプラインや IBM Cloud Schematics に移行することができます。

以下のツールが必要となりますが、これらがプレインストールされている IBM Cloud Shell を使用するか、これらがインストールされているご自身の環境を使用してください。これらのツールのインストールに関するヘルプは、ソリューション・チュートリアルの開始 を参照してください。

• Git
• IBM Cloud CLI
• Terraform
• Jq

IAMの前提条件

VPCリソースを作成するには、パーミッションが必要です。アカウントの所有者であっても、スプーフィングを許可するネットワーク・インターフェースを持つインスタンスを作成するには、追加のIAMポリシーが必要です。IPスプーフィングのチェックのチェックについてを参照してください。

私はアカウント管理者なので、自分のメールアドレスを使ってCloud Shellで以下のコマンドラインを実行しました。

ibmcloud iam user-policy-create YOUR_USER_EMAIL_ADDRESS --roles "IP Spoofing Operator" --service-name is

または、IBM Cloud Console の IAM セクションのユーザーまたはUsersからこのポリシーを追加することもできます。

• ユーザーまたは Userをクリックします。
• アクセス・ポリシー または Access policies をクリックします。
• アクセス権限の割り当て または Assign access をクリックします。
• IAM サービスまたは IAM Service をクリックします。
• ドロップダウンから VPC Infrastructure Services を選択します。
• IP Spoofing Operator をクリックします。

作成とテスト

ソースコードリポジトリをクローンして、ツールの前提条件チェックを実行します。

git clone https://github.com/IBM-Cloud/vpc-nfv-squid
cd  vpc-nfv-squid
cp local.env.template local.env
edit local.env
source local.env
./000-prereq.sh

リソースを作成します。スクリプトを見てみましょう。とてもシンプルです。

cat ./010-create.sh
#!/bin/bash

terraform init
terraform apply -auto-approve

もしTerraformがプロキシインスタンスをプロビジョニングできず、以下のエラーメッセージを出す場合は、IP Spoofing Operatorのパーミッションが、上記のようにアカウントに正しく設定されているか確認してください。

Error: the provided token is not authorized to  the specified instance (ID:NEWRESOURCE) in this account

TerraformのHeavy Liftingはmain.tfで定義されています。Terraformに馴染みのない方でも、ぜひご覧ください。Terraformが正常に完了したら、IBM CloudコンソールでVPCレイアウトを開き、すべてのサブネットを選択します。ここでは、Squidのlocal.envにベースネームを設定しました。

テストスクリプトを実行して、期待通りに動作していることを確認します。プロンプトが表示されたら、sshのIPアドレスを受け入れてください。

$ ./030-test.sh

>>> verify it is possible to ssh to the host and execute the true command
ssh -J root@52.116.133.164 root@10.0.0.4 true

>>> verify proxy connectivity using ping
ssh -J root@52.116.133.164 root@10.0.0.4 ping 10.0.1.4 -c 2
PING 10.0.1.4 (10.0.1.4) 56(84) bytes of data.
64 bytes from 10.0.1.4: icmp_seq=1 ttl=64 time=0.540 ms
64 bytes from 10.0.1.4: icmp_seq=2 ttl=64 time=0.422 ms

--- 10.0.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1013ms
rtt min/avg/max/mdev = 0.422/0.481/0.540/0.059 ms

>>> verify explicy specifying the squid proxy server ip works. Testing the network path - not testing the router
ssh -J root@52.116.133.164 root@10.0.0.4 set -o pipefail; curl neverssl.com -s --proxy 10.0.1.4:8080 | grep poorly-behaved > /dev/null

>>> veriy direct access to neverssl.com, end to end, through the route table
ssh -J root@52.116.133.164 root@10.0.0.4 set -o pipefail; curl neverssl.com -s | grep poorly-behaved > /dev/null

>>> verify implicit access to a denied host fails
ssh -J root@52.116.133.164 root@10.0.0.4 curl virus.com -s | grep squid > /dev/null
>>> success

テストドライブの要領で、作成したシステムをさらに深く掘り下げてみましょう。

ジャンプインスタンス

sshで直接アクセスできるのはjump (bastion)のインスタンスだけです。main.tfのsecurity group ssg_sslをチェックしてみてください。要塞ホストを使用してリモート・インスタンスにセキュアにアクセスすることで詳細を把握することができます。Terraformの出力には、jumpを介してホストにsshするのに使えるコピー/ペーストの文字列があります。残りのテストはjumpホストを使って行います。テスト結果を確認してみましょう。ここでは次のようになりました。

$ terraform output host 
[
  {
    "ip_host" = "10.0.0.4"
    "sshhost" = "ssh -J root@52.116.137.7 root@10.0.0.4"
  },
]
$ ssh -J root@52.116.137.7 root@10.0.0.4
...
root@squid-us-south-1-host:~# 

ホストからプロキシへのアクセス

最後のステップでは、ホストにsshしました。いくつかのテストを再現してみましょう。プロキシは到達可能ですか？

root@squid-us-south-1-host:~# ping 10.0.1.4 -c 2
PING 10.0.1.4 (10.0.1.4) 56(84) bytes of data.
64 bytes from 10.0.1.4: icmp_seq=1 ttl=64 time=0.532 ms
64 bytes from 10.0.1.4: icmp_seq=2 ttl=64 time=0.428 ms

--- 10.0.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1020ms
rtt min/avg/max/mdev = 0.428/0.480/0.532/0.052 ms

次に、プロキシ上でSquidサービスが実行されており、Squidがインターネットに到達できることを確認します。Squidはポート8080をリッスンしているので、以下のcurlで動作するはずです。

root@squid-us-south-1-host:~# curl neverssl.com -s --proxy 10.0.1.4:8080
<html>
    <head>
        <title>NeverSSL - helping you get online</title>
...

ネットワーク仮想化によるホストアクセス

VPCルーティングとNFVの美しさは、ルーティング・テーブルを開き、VPCを選択して、ルートテーブルをクリックすることで見ることができます。

10.0.0.0はVPCのCIDRです。166.8.0.0と161.26.0.0のCIDRは、ソフトウェア・リポジトリ・ミラー、タイム・サーバー、dnsサーバーなどへのIBMクラウドのサービス・エンドポイントです。利用可能なエンドポイントを確認してください。これらはすべて、デフォルトのルーティング・テーブルに委ねられています。詳しくは経路の作成を参照してください。

面白いことにCIDRである0.0.0.0/0は、他のすべてと一致しています。次のホップ – 10.0.1.4 – はプロキシです。ホストがIPアドレス54.230.154.14のneverssl.comに接続すると、このルートにマッチし、プロキシインスタンスへの接続が行われます。

SquidサービスとLinux iptablesは proxy_user_data.sh ファイルで設定されています。次のコマンドに注目してください。

iptables -t nat -I PREROUTING 1 -s $host_ipv4_cidr_block -p tcp --dport 80 -j REDIRECT --to-port 3129

プロキシで実行された上記のiptablesコマンドは、受信パケットの一部をSquidアプリケーションのインターセプト ポートに向けるようにカーネルのルーティング・テーブルを構成します。それを分解してみましょう。

• -t nat:  Add entry #1 in the network address translation table.
• -s $host_ipv4_cidr_block: Only consider those packets from the host cider blocks.
• -p tcp: Only consider tcp protocol.
• -dport 80: Only consider packets to port 80 (http).
• -j REDIRECT: Redirect the matching packets.
• –to-port 3129: Change the destination port from 80 to 3129.

あとは、Squidの設定で行います。

cat > /etc/squid/squid.conf <<EOF
visible_hostname squid

#Handling HTTP requests
http_port 3129 intercept
http_port 8080
acl allowed_http_sites dstdomain .neverssl.com
acl allowed_http_sites dstdomain .test.com
acl allowed_http_sites dstdomain .ubuntu.com
http_access allow allowed_http_sites
EOF

Squidはポート3129でパケットをインターセプトし、仲介役を務めます。許可されるサイトは、neversl.com、test.com、ubuntu.comの数サイトのみです。その他のサイトはすべてSquidによって拒否されます。これで下の図の意味が理解できることでしょう。

テストを続けます。

root@squid-us-south-1-host:~# curl -s neverssl.com
<html>
    <head>
        <title>NeverSSL - helping you get online</title>
...

設定はルートテーブルに集約され、設定されたサブネット上のインスタンスに適用されます。ホストインスタンスは、Squidを介してインターネットにアクセスするための設定は必要ありません。もしあなたが、エンド・ツー・エンドの会話を盗聴できたとしたら、次のようになります。

tcpパケットの送信元と送信先のIP番号は、明示的に記載されているものを除き、予想通りです。

1. リクエストは 54.230.125.14 に宛てられています。ルートテーブルのネクストホップルートは、10.0.1.4のプロキシにそれを届けます。
2. プロキシでは、Linux iptablesがSquidプロセスにリダイレクトします。Squidプロセスはneverssl.comへの接続を確立します。このIPアドレスはパブリックゲートウェイによって提供されます。
3. 応答はパブリックゲートウェイ経由でプロキシ/Squidに返されます。
4. Squidはneverssl.comになりすまし、IPアドレス54.230.125.14を偽装します。ホスト上で実行されているcurlコマンドには何の影響もありません。

tcpdumpを使用すると、トラフィックの一部を見ることができます。プロキシへの別の ssh セッションを立ち上げます。sshコマンドはTerraformの出力を使用して検出されます。プロキシではtcpdump port 80を実行し、ホストでも同じことをしますが、バックグラウンドのtcpdump port 80 & にします。その後、フォアグラウンドのホスト上で、再びcurlコマンドを実行します。以下の文章は読みやすいように編集されています。

プロキシの場合:

root@squid-proxy:~# tcpdump port 80
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
22:27:38.344635 IP 10.0.0.4.59434 > server-54-230-125-14.dfw50.r.cloudfront.net.http: Flags [S],
22:27:38.344774 IP server-54-230-125-14.dfw50.r.cloudfront.net.http > 10.0.0.4.59434: Flags [S

ホストの場合:

root@squid-us-south-1-host:~# tcpdump port 80 &
root@squid-us-south-1-host:~# curl -s neverssl.com >/dev/null
22:27:38.228500 IP squid-us-south-1-host.59434 > server-54-230-125-14.dfw50.r.cloudfront.net.http: Flags [S]
22:27:38.229147 IP server-54-230-125-14.dfw50.r.cloudfront.net.http > squid-us-south-1-host.59434: Flags [S

Squidがvirus.comへのアクセスを拒否することを確認します。Squidのエラーメッセージに注目してください。

root@squid-us-south-1-host:~# curl -s virus.com
...
<p>Generated Mon, 15 Mar 2021 22:41:20 GMT by squid (squid/3.5.27)</p>
<!-- ERR_ACCESS_DENIED -->
</div>
</body></html>
root@squid-us-south-1-host:~#

クリーンアップ

調査が終わったら、./040-cleanup.shを使ってすべてのリソースをクリーンアップします。
スクリプトを見てみましょう: terraform destroy.

まとめ

ネットワーク仮想化（NFV）用にVPCのルーティング・テーブルを設定することは、VPCネットワークに透過的に機能を入れ込む優れた方法です。より一般的には、ルートテーブルと経路を使用して、ネットワーク接続を分離したり拡張したりすることができます。

SquidをHTTPSトラフィックで動作するように設定して NFVをより深く体験してください。SslBump Peek and Splice を参照

以下のNFVは、IBM Cloud Catalogでもご覧いただけます。

• Palo Alto Networks VM-Series Next-Generation Firewall (BYOL) on IBM Cloud VPC
• F5 BIG-IP Virtual Edition for VPC

翻訳：IBM Cloud Blog Japan 編集部

*このブログは、2021/3/22に発行された“Network Function Virtualization (NFV) Using VPC Routing”(英語)の抄訳です。