VPCピアリング先のプロキシサーバーへの通信を検証してみる

はじめに

少し特殊なケースですが表題の件について、CloudFormationで検証環境を構築して確かめてみました。 次章:背景 でも話しますが、検証したい本番の環境は以下の通り。

背景

Direct Connect (DX) のサービスによっては、AWS側のネットワーク構成・通信用件に制限があったりします。 例えば、 VPCの CIDRはプロバイダの指定値にする などです。 外部サービスのセキュリティ設定で、 指定 CIDRの IPアドレス以外からの接続を拒否 しているケースなどでしょうか。

要件通り新規VPCを作成したとします。 やりたいことは 既存環境の APPサーバーが この新規VPC経由で DX先の外部サービスを利用する 、です。

できないパターン: NATゲートウェイ、NATインスタンス

NAT(Network Address Translation) を利用しての通信は できません 。

(2019/11/12 追記) 今回はVPCピアリングを利用しているため、ルーティングの制約上できませんが、 Transit Gateway を使って接続した場合、 NATインスタンスを利用してDX先の外部サービスと通信することは可能です。

マネージドな NAT Gateway はそもそもインターネット向けの用途で、 ローカル環境の NATはサポートしていません 。 そもそも NATインスタンスを立てたとしても、 VPCピアリングの制約上 推移的なエッジツーエッジルーティングは サポートしていません。

(引用: サポートされていない VPC ピア接続設定)

できるパターン

そのような背景があっての表題です。 NATとの違いは、レイヤーの違いです。 アプリケーションレイヤーでデータを中継します。

とはいえ、実際に通信できるか心配なのでこれから検証します。

環境構築

検証環境は以下のとおりです。

DX側の環境は VPCピアリングで代用しています。 VPCピアリングも同様に推移的なピアリング接続はできないため、DXと似たような条件になります。

(引用: サポートされていない VPC ピア接続設定)

APPサーバーから Proxyサーバー経由で Serviceを利用できるか確かめてみます。 構築は勉強も兼ねて CloudFormation(CFn)で行います。

github に今回作成した CFnテンプレートを上げています。

• 00-network.yaml: ネットワークリソース作成用
• 01-sg.yaml: セキュリティグループ作成用
• 10-ec2-proxy.yaml: Proxyサーバー (Linux)作成用
• 11-ec2-app.yaml: アプリサーバー (Windows) 作成用
• 12-ec2-service.yaml: サービスサーバー (Linux) 作成用

VPCピアリング部分

同一アカウントの場合、リソースのプロパティ項目はそこまで多くありません。 VpcId と PeerVpcId にそれぞれピアリング接続するVPCのIDを記述します。

VPCPeering:
  Type: AWS::EC2::VPCPeeringConnection
  Properties: 
    VpcId: !Ref VPC1
    PeerVpcId: !Ref VPC2

ルートテーブルに VPCピアリング向きのルートを追加します。

Route1b:
  Type: AWS::EC2::Route
  Properties:
    RouteTableId: !Ref RouteTable1
    DestinationCidrBlock: 10.0.0.0/24
    VpcPeeringConnectionId: !Ref VPCPeering
# ...
Route2b:
  Type: AWS::EC2::Route
  Properties:
    RouteTableId: !Ref RouteTable2
    DestinationCidrBlock: 192.168.0.0/24
    VpcPeeringConnectionId: !Ref VPCPeering

プロキシ設定 (クライアント側)

以下のように ユーザーデータにスクリプトを入れています。

• 1行目: プロキシの有効化
• 2行目: プロキシサーバーIPアドレスを、作成したプロキシサーバーのローカルIPに指定

AppInstance:
  Type: AWS::EC2::Instance
  Properties:
    # ...
    UserData:
      Fn::Base64: !Sub |
        <powershell>
        reg add "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /f /v ProxyEnable /t reg_dword /d 1
        reg add "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /f /v ProxyServer /t reg_sz /d ${ProxyIp}:3128
        </powershell>

(参考: Internet Explorer のプロキシの設定をコマンドで実行する方法 )

プロキシ設定 (サーバー側)

プロキシのソフトウェアとして squid をインストールします。

その後、 /etc/squid/squid.conf を編集します。 基本的にデフォルト設定で大丈夫でした。 acl localnet src xxx の部分をプロキシのクライアント側ネットワークとします。

acl localnet src 192.168.0.0/24	# VPC Network (Application side)

検証

APPサーバーにログインして、Service-VPCにある サービスを利用できるか検証します。 (Serviceの EC2インスタンスには httpd を入れておきます)

APPサーバーにログインして、ServiceのローカルIPに httpアクセスしてみます。

▲繋がりました。

サービスの httpdのアクセスログを見てみます。

▲プロキシサーバーからのアクセスを確認できました

おわりに

あっさりとした検証内容でしたが、VPCピアリング先のプロキシサーバーを利用することができました。 今後はプロキシサーバーを冗長化させる際の考慮点など、まとめていきたいと思います。