この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
少し特殊なケースですが表題の件について、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ピアリング先のプロキシサーバーを利用することができました。 今後はプロキシサーバーを冗長化させる際の考慮点など、まとめていきたいと思います。
8
