想定
- オンプレミス環境に強制トンネリングしている環境でHTTP系の通信をプロキシサーバに向けている
- 一方で特定の通信(例えばMS系の通信)をAzure Firewall経由でバックボーンネットワークに流したい
- 結論PACファイルで制御
- これをAzure環境で検証します‼
環境
- 基本はこちらのBicepから展開
- BGP有効化したS2SVPNでVNET同士を接続し、片側をオンプレ想定する環境
- 基本イメージ
<Azure上でS2SVPNをサクッと構築するためのBicep>
↑の改良版
- これを拡張して
オンプレミスに強制トンネリングしつつ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
おわり
オンプレ側・Azure側、どちらにもインターネットへの出口がある場合、強制トンネリングがあると一癖あるため検証してイメージがつかめた。基本構成として利用したBicepは必要最低限の構成が故、可搬性に長けていて便利なのでもう少し作りこもうと思います。
GitHubで編集を提案
Discussion