はじめに
先日、Azure Application Gateway (AppGw) の TCP/TLS プロキシ機能がプレビューで利用可能となりました[1]。これにより、従来のレイヤー 7 機能 (HTTP、HTTPS、WebSocket、HTTP/2) に加えて、レイヤー 4 (TCP プロトコル) もサポートされるようになります。
リバースプロキシサービスとして、AppGw のレイヤー 4 操作はレイヤー 7 プロキシ操作と同様に機能します。クライアントは AppGw との TCP 接続を確立し、AppGW 自体がバックエンド プールのサーバーと新しく TCP 接続を開始します。
L4 というと、Azure Load Balancer (ALB) が既に存在しますが、大きな違いとしてはクライアントとバックエンド サーバーの間で直接接続を確立するのが ALB、クライアントとの接続を一旦終端するのが AppGw です。
TCP 接続を試す
環境
代表的な L4 TCP プロトコルとして Remote Desktop Protocol (RDP) を使って検証します。
簡易的に次のような環境を構築していきます。
Application Gateway
Application Gateway をデプロイするには専用のサブネットが必要になるため、バックエンド VM 用とは別にサブネットを切り、そこにデプロイします。
ルーティング規則は次のように設定します。リスナーの設定として、プロトコルには TCP を選択し、ポートには 3389 を選択します。待ち受けポートになるので、クライアント側で指定できるのであれば 3389 以外でも問題ありません。
VM
バックエンド サーバーとなる VM を VM 用のサブネットにデプロイします。パブリック IP は不要です。作成後、AppGw のバックエンド プールに追加しておきましょう。
接続してみる
AppGw のフロントエンド IP に対して RDP 接続します。
RDP クライアントから接続すると問題なく接続できました。
VM 用サブネットに関連付けた NSG には既定のルールしか入っていないため、接続元 IP を許可していない状態ですが接続できています。これは、AppGw が一度終端して AppGw から VM への内部通信となっているからですね。この状態では Application Gateway が公開された踏み台サーバーという状態となっているため、内部 Application Gateway の場合には利用の余地がありそうですね。
おわりに
本記事では AppGw の TCP/TLS プロキシについて、TCP の部分について検証しました。FQDN や IP アドレスにより Reachable なオンプレミス環境等にもアクセスすることができるため、PaaS でプロキシを用意したい場面では有用でしょう。
Discussion