AWS Client VPNとAzure P2Sを比較してみた
前回の記事からの続きです。
AWS Client VPNでオンプレミスのPCをAWSのVPCに接続し、その際にインターネットに出るIPアドレスをAWSの固定IPアドレスにする、という構成です。
ネットワークの用語でいうとフルトンネル(フルトンネリング)という構成です。
NAT GatewayにElastic IPアドレスを設定し、AWS Client VPNでインターネットに出る際、IPアドレスをElastic IPアドレスに固定する(固定IPアドレスにする)というシナリオです。
今回はAWS Client VPNのクライアントPC側の設定です。
Azure P2Sは証明書インストールとP2Sのエージェントインストールのみなので大した作業ではないのですが、AWS Client VPNは運用観点も絡めるとまぁまぁ面倒な設定があるので比較のためにも記事にしました。
AWS Client VPNの構成図と本記事の作業箇所
普段AzureのP2Sを構築していて当然構成図も書いたことがあるのですが、AWSの構成図は初めて書きます。
お作法も分からないので間違っていればご指摘ください。
このような構成図になります。
前回と同じですね。
今回の記事では赤枠部分の設定です。
1. AWS Client VPN設定ファイルのダウンロード
前回の記事で作成したクライアント VPN エンドポイントの設定画面で赤枠内のクライアント設定をダウンロードをクリックします。
downloded-client-config.ovpn
というファイルがダウンロードされます。
もう証明書もクライアント VPN エンドポイントも削除してしまっているのでセキュリティ的に問題が無いので、この.ovpnファイルの中身も晒してしまいます。
このような中身になっています。
remoteの項目がAWS Clinet VPN接続先になります。
ちゃんとポートが前回の記事の設定どおり443になっていますね。
なんとこの設定ファイルに追記する必要があります。
追記方法は2種類ありますが、追記する、という作業は必須です。
いや、AWS側の設定もめちゃくちゃ面倒やったのに、クライアントPC側でも手間かけさせるの？
マジで？めっちゃ面倒やん。
ってのが正直な感想です。
比較記事なので、この辺はまとめの比較部分で感想じゃなくてちゃんと比較した結果で記載します。
肝心の追記項目ですが、結果からいうと以下の赤枠ようになります。
はい、前回の記事のクライアント証明書のダウンロードでダウンロードしたクライアント証明書とクライアントキーのクライアントPC側での格納先(ファイルパス)を.ovpnファイルに直接書き込みます。
ファイルパスじゃなくて、.crtファイルと.keyファイルをテキストで出力した結果を直接書き込む方式もありますが、ファイル内容を直接書き込んでしまうとこの.ovpnファイルが漏えいしたらインターネット上に公開されているAWS Clinet VPNのエージェントが手に入ったらVPC内に自由に出入りできてしまいます。
これはかなり危険な状態です。
私はファイルパス記載を推奨します。
.ovpnファイルの漏えいのリスクを考慮すると、この.ovpnファイルはあくまで設定ファイルまでの記述に留め、実際の認証や通信の復号化に使われる.crtファイルと.keyファイルはファイルパスでの記載とし、別管理とした方がセキュリティレベルが上がる、と考えるからです。
.ovpnファイルにユーザが追記する、という仕組みは非常に面倒ですが、こういった部分に考慮の余地があるのはエンジニアの腕の見せ所かなと思います。
お付き合いのSIerさんにこの辺突っ込んで聞いてもらうと、そのSIerさんがどこまで何を考慮してるか透けて見えると思います。
まぁドメイン認証にしてもらった方がより細かな制御が可能ですが、それは今回の比較記事とは別企画で進めようと思います。
注意
ファイルパスの記載ですが、Windowsの場合￥ではなく、￥￥と￥が2回続けて記載しなければなりません。
2. AWS Clinet VPNエージェントのダウンロードとインストール
こちらからダウンロードしてインストールしてください。
https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-user/client-vpn-connect-windows.html
3. AWS Client VPNエージェント設定
AWS Clinet VPNのインストールが完了したら、AWS Clinet VPNを開いてください。
このような画面が起動しますので、言うとおりに[ファイル]から[プロファイルの管理]を開きましょう。
プロファイルを追加をクリックし、この項目通りに変更済みの.ovpnファイルを指定しましょう。
プロファイル名を付けて保存するとプロファイルが出てきます。
.ovpnファイルに設定不良がある(例えば.crtファイルと.keyファイルの記載がない)と怒られますので、この画面まで出たら安心してください。
3. AWS Clinet VPNを接続する
接続！
前の記事で設定したログインバナーの文字がちゃんと出力されました！
確認くんなどでグローバルIPアドレスを確認してください。
こちらも当然ですが前の記事で確認したグローバルIPアドレスになっています。
ゲートウェイの名前もバッチリAWSだということがわかる構成になっていますね。
これでAWS Clinet VPNでフルルート、固定IPアドレス化を行う、という当初の目標は達成できました！
4. AWS Clinet VPN経由でVPC内のEC2にアクセスする
これ、微妙にハマったので記載しておきます。
結局この構成だと、クライアントPCに割り当てられるのはどのIPアドレスなの？
どこのリソースにアクセスする際にどのIPアドレスになっているの？
というのがわからなくなったので整理しました。
4-1. AWS Clinet VPNのクライアントPCに割当たるIPアドレス
AWS Clinet VPN接続時にはこの設定項目で設定した、10.255.0.0/22のIPアドレスが割当たります。
構成図でいうとこんな感じ。
赤字の部分ですね。
なので、このIPアドレス、10.255.0.0/22をPublic SubnetにあるEC2に割当たっているセキュリティグループで許可しても該当のEC2にアクセスできない・・・
・・・マジか・・・
・・・めんどいわぁ～
って感じです。
でもよくよく考えてみると、VPN Gateway経由でPublic SubnetのEC2にアクセスする時点でVPN Gatewayの存在しているPrivate SubnetのIPアドレスにNATされてるんですよね。
この赤字の太字、172.16.101.0/24に10.255.0.0/22がNATされてるんです。
で、恐らくこのNATを行っているパラメータが前の記事のここ
再度画像を掲載すると
ここですね。
よくみるとこのルートテーブルの設定、
追加で赤枠で囲ったタイプのとこがNATになってるんですよね。
きっとAWSを普段から使ってるエンジニアはこの辺りも抜かりなく理解されてるんでしょうね。
素晴らしいですね。
これらの結果をまとめると、EC2に割り当てているセキュリティグループの設定値はこのようになります。
この例ではICMPv4しか許可していませんが、RDPやSSHなど、必要なサービスを許可してください。
AWS Clinet VPN、正直便利です。
でもね、いや、ホント、マジでめんどくさかったです。
Azure P2Sは普段やり慣れてるのもあるかもしれませんが、設定はもっと簡単です。
まだまだこの企画は続きますので、良ければお付き合いください。
本日はここまで。