想定
- オンプレミス環境に強制トンネリングしている環境で HTTP 系の通信をプロキシサーバに向けている
- 一方で特定の通信(例えばMS系の通信)を Azure Firewall 経由でバックボーンネットワークに流したい
- 結論 PAC ファイルで制御
環境
- 基本はこちらの Bicep から展開
- BGP 有効化した S2SVPN で VNET 同士を接続し、片側をオンプレ想定とする環境
- 基本イメージ
- これを拡張して
オンプレミスに強制トンネリングしつつ Azure Firewall からも一部のトラフィックを外に出す環境を構成
変更点
VPN Gateway
- クラウド側 VPN Gateway の DefaultSite にオンプレ側の Local Network Gateway を指定
- オンプレ側にデフォルトルートを広報するサーバを用意する手順が煩雑のため
- 下記コマンドにおいて、Local Network Gateway と VPN Gateway は同じリージョンにないとエラーになるためリージョンを分けている場合は注意
- To オンプレミスを考えると、VPN Gateway とオンプレミスをあらわす Local Network Gateway は通常同じリージョン
$LocalGateway = Get-AzLocalNetworkGateway -Name "<ONPREMISE-LNG>" -ResourceGroupName "<YOUR-RG-NAME>"
$VirtualGateway = Get-AzVirtualNetworkGateway -Name "<CLOUD-VPNGW>" -ResourceGroupName "<YOUR-RG-NAME>"
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
- DefaultSite を構成すると自動的にその VPN Gateway の影響範囲の VM にルートが広報される
- 下記画像ではその広報された
次ホップ:仮想ネットワークゲートウェイをさらに UDR で上書きしているため、無効となっている
Windows VM
- プロキシサーバの設定等が分かり易いため、クライアント想定の Windows Server をクラウド側にデプロイ
- 強制トンネリング環境下では Azure Firewall 経由で RDP するため NSG の穴あけは不要
- パブリック IP の付与されている VM への直接 RDP は、強制トンネリングの影響または
0.0.0.0/0->AzureFirewallの UDR の影響を受け、非対称となるため接続不可
- パブリック IP の付与されている VM への直接 RDP は、強制トンネリングの影響または
Azure Firewall
- 今回の主役
- AzureFirewallSubnet を作成してデプロイ
DNATルール
- Windows VM への RDP 用ルールとして DNAT ルールを追加
- 例
- ソース：アクセス元 IP
- ターゲット：Azure Firewall のパブリック IP
- ポート：Azure Firewall の待ち受けポート
- 変換されたアドレス：Windows VM のプライベート IP
- 変換されたポート：3389
アプリケーションルール
- Windows VMがAzure Firewall経由で外に出ていく場合のFQDN許可ルールを作成
- 例（ざっくり）
- Source: 10.0.0.0/16
- Protocol: http:80, https:443
- Destination Type: FQDN
- FQDNs: *
ルートテーブル
Windows VM サブネット用
- PAC ファイルによって
DIRECTが選択された場合、Azure 環境からは構成されているルーティング設定に従う - 特定( MS 系)の通信を
DIRECTに向けるとして、その際に Azure Firewall を向けたい -
0.0.0.0/0または特定のサービスタグを Azure Firewall に向けるルートテーブルを作成し、 Windows VM の所属するサブネットに関連付ける -
オンプレ側の VPNGW でネクストホップとなる NVA を指定しておけば、DIRECTでオンプレを向けることはできるかも- GatewaySubnet に
0.0.0.0/0のルートはアタッチできません
- GatewaySubnet に
AzureFirewallSubnet用
- Azure Firewall 自体が強制トンネリングの影響を受けないようにルートテーブルが必要
-
0.0.0.0/0をInternetに向けるルートテーブルを付与-
ルートの伝達を無効にするだけでもよいかと思ったが、AzureFirewallSubnetに関連付けるルートテーブルには0.0.0.0/0のルートが必要
-
プロキシサーバ(Squid)の構成
- こちらの記事を参考に構成
- プロキシはパケットを転送しているわけではないのでNICでのIP転送の設定は不要
PACファイル
- 以下のような簡易的PACファイルを作成
-
.b4iine.net([確認君+])はDIRECTでアクセスさせ、それ以外はオンプレプロキシを通すようなイメージ
-
function FindProxyForURL(url, host) {
if (isPlainHostName(host) || dnsDomainIs(host, ".b4iine.net")) {
return "DIRECT";
} else {
return "PROXY 10.100.1.4:3128";
}
}
ファイルサーバ
- PAC ファイルを Windows VM 上で指定するためにはどこかしらの http アクセス可能なサーバに公開する必要がある
- 本検証では Azure Blob Storage に配置しました
Windows VM 上での PAC ファイル指定
-
inetcpl.cplを実行し、Connections>LAN Settingsから設定する
検証
下記サイトにアクセスし、表示される IP アドレスを確認する
- 確認君+(https://env.b4iine.net/) -> Azure Firewall のパブリック IP
- それ以外のドメインの IP 確認サービス -> Proxy サーバのパブリック IP
- 例：安全な確認くん(https://kakunin.net/kun/)
-
Azure Firewall のパブリック IP
-
Squid Proxy サーバのパブリック IP
おわり
強制トンネリング環境下で一部通信を透過型プロキシを通して外に出せるかを検証しました。本構成では、DIRECT に載せてトラフィックを運ぶため、指定が可能な明示的なプロキシを用いる場合はもう少し設定がシンプルになるはずです。ちなみに、Azure Firewall にも明示的なプロキシ機能がありますが、現在プレビュー段階です。
GitHubで編集を提案
Discussion