LoginSignup
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@smr1

Azure でNetwork Routing（UDR、Firewall、Load Balancer、Application Gateway、Front Door）

Last updated at Posted at 2024-10-27

User Defined Route

  • Subnet単位で指定
  • 適用されたSubnetからの外部向け通信を制御する
  • 詳細度が高いRouteのほうが優先される（10.0.0.0/24 > 10.0.0.0/16）

image.png

Azure Firewall

Azure FirewallってStandard機能だけだと結局ルーティングがメインのリソースな気がする。NAT Rule、Network Rule、Application Ruleについてはこちら参照。

かつならNSGとAzure Firewallの違いとは？と分からなくなってくるので、自分の未来のために（一度上の記事に貼っているけど）参考リンクをペタリ。

image.png

Azure Firewallによる強制トンネリング

ちゃんと理解できたか微妙だが自分の理解を書くと。
強制トンネリングとはAzure上のVMから直接インターネットに出る前にオンプレのNVAなどに通信を向けて、監査用にスクリーニング、ロギング等させること。
VNetにAzure FirewallとVMがある構成で、インターネット向け通信は全てAzure Firewallを通し、Azure FirewallからDestinationとして監査用NVAに通信を向ける。
※ここではAzure Firewallの勉強の文脈で出てきたため、こちらを使っているが、オンプレのNVAに向けるのであればVPN GatewayでTunnelingしたほうがいいらしい。

ただ、以下の記事によると逆にオンプレの通信をクラウド上のNVAを通したいということもあるらしい。

image.png

  • Azure Firewallの強制トンネルリングを有効化
    • 有効化のためにAzureFirewallManagementSubnetとPublic IPが必要
    • これは一般ユーザーの通信と管理の通信（Threat Intelligence等）を分離するという意味で有用
  • VMをデプロイしたSubnetにRoute設定
    • Routeで0.0.0.0/0 = Internetあての通信をFirewallに向ける

自分でスクショ取りながらやっていたが、こちらにきれいにまとまっていた記事があったので、、、感謝。（こちらは1つのVNetでやっているぽいので上の図とはちょっと構成が違うが。）

ちなみに強制トンネリングを有効にするとAzure Firewallを通るようになるので、VMへのRDPがつながらなくなってしまう事象が発生した。テスト用にお金をケチってPublic IPに対してRDPしていたのが悪い。
Perplexityに壁打ちして気づいたのだが、強制トンネリングをするとRDPの通信もAzure Firewallに向いてしまい、RDPを許可していないのでブロックされると。Bastionなら影響されないらしいのでBastionの利用をお勧めする。

ルーティングのトラブルシュート

VMのトラブルシュートであれば、以下が可能。

  • Network WatcherのIP Flow Verifyで疎通を確認できる
    image.png
    どのNSGルールにより許可されたかが表示される、ここではVNetPeeringしたVM間の疎通確認。ただし、どのNSGかが書かれていない。。
    image.png

  • NICのEffective RouteでどのRoutingが有効化を確認できる
    image.png

Network WatcherはVNetを作成すると自動的に作られるのでそれを使うこともできる。

  • Network WatcherのNext Hop
    image.png

  • Network WatcherのConnection Troubleshoot
    VMから外部のIPへの通信状況、レイテンシとかも出せる
    image.png

  • NSGの通信ログであるFlow LogをLog Analyticsに蓄積・分析してNSGのネットワークトラフィックをTraffic Managerから傾向を分析できる。

負荷分散リソース

Azure PortalでLoad balancerで検索すると以下のように選択するための情報が出てくる。

image.png

Load Balancer

image.png

  • エンタープライスユースだと（AZ分散、NSGによるセキュリティ等）Standardが必須
  • PublicとPrivateの分散が可能
  • OSI レイヤー4による分散
    • ソースIP、ソースポート
    • 目的IP、目的ポート
    • プロトコル

Regionまたぎの分散も可能。
image.png

汎用的な負荷分散なので、バックエンドはVMでもDBでもなんでも可能。

image.png

Application Gateway

  • Webアプリ用
  • Layer 7の負荷分散、HTTP、HTTPS用、パスベースルーティングが可能
  • Auto Scalingやゾーン冗長がある
  • Internal、Publicの設定が可能
  • WAFとの統合が可能
  • TLS終端が可能（バックエンドがHTTPを受け付けるので、CPU不可軽くなり、証明書設定も不要）

image.png

メインどころの設定を書くと、

  • FrontendとしてPublic IP、Private IPを持てるが、Private IPだけというのはできない
    →と思ったらプレビューだがPrivateのみのApplication Gatewayも設定できるぽい

  • Listenerは複数に複数ドメインホスト用にマルチサイトとすることも可能（contoso.com、fabrikam.com等）

  • ルーティングは ベーシック（constoso.com/*）にするか、パスベースにするか選択、これによりどのBackend Poolに流すかを決める
  • Backend PoolはFQDNやIPアドレスにすることも可能

image.png

Deploy

image.png

image.png

色々選べる。VM立てるのも面倒なので、適当なサイトを宛先にしてみる。
image.png

RuleでListenerを設定。
これはApplication Gatewayの受け取り側のルール。
502や403のエラーに対してSooryページ等が表示できる。
image.png

今度はタブをBackend targetsに切り替え、Application Gatewayから流す通信の詳細を決定する。IPではなくCookieベースセッションアフィニティもできる。
image.png

image.png

image.png

SSL オフロード

ちなみにSSLオフロードをするには、RuleのListenerでHTTPSにしてKeyVaultに証明書を格納しBackend targetsでHttpで流すようにすればよいらしい。これによりバックエンドには未暗号の通信になる（未検証）。ただしAzure バックボーン通信になるのでそれが危険というわけではない。

image.png

Application Gatewayカスタムドメイン

Application Gatwayにカスタムドメインを構成するにはこちらを参照。App GWとWebApp両方にカスタムドメイン設定してしまうのがきれいポイ。

image.png

試してみた手順はこちら。

RedirectとRewrite

  • AppGWでRedirect
    以下のようなパターン
    • HttpをHttpsにRedirectさせる
    • 外部サイトへのRedirect

  • Rewriteは
    • RequestやResponseヘッダの編集
    • クエリストリングをURLパスからクエリストリングへの変換等
      f.ex. /article/123を/article?id=123にする
      こんな感じのRewriteルールが設定可能。
      image.png
      image.png

Health Probe

シングルサイトの場合は宛先を127.0.0.1にできる。
image.png
テストもできる。GoogleはhealthがあるのでOK。
image.png

Front Door

  • Globalリソース
  • レイテンシに基づいたルーティング
  • Layer 7の負荷分散
  • Auto Scalingやゾーン冗長がある
  • キャッシング
  • WAFとの統合が可能

複数リソースの機能（Traffic Manager、Application Gateway、WAF、CDN）を統合しているので、リソースをシンプル化できる可能性がある。

以下のようなマルチリージョンアプリに向いている。
image.png

image.png

Standardは配信機能に特化しており、Premium SKUはPrivate Endpoint、WAF、Threat Intelligence等追加でセキュリティ機能が追加される。

Deploy

GlobalリソースなのでRegionを選ぶ必要がない。
image.png

カスタムドメインを設定する場合はKey Vaultを設定。
image.png

エンドポイントを作成。
image.png

エンドポイントに複数のルーティングを入れられ、個別のWAF Policyを設定できる。
image.png

Origin -> 実際のバックエンド（URL、IP、Web Apps、Container等を設定する、接続先ポート等もここで）
image.png
接続先は選択可能なものがたくさん。CustomにすればFQDNやIPベースもOK。
image.png
ルーティングの優先度
image.png

OriginGroup -> 複数のOriginを設定する（Health ProbeやLoad Balancing Optionなどを設定）

The latency sensitivity with value zero (0) means always send it to the fastest available backend, else Front Door will round robin traffic between the fastest and the next fastest backends within the configured latency sensitivity

Load Balancingで通常は一番早いのと2番目に早いエンドポイントでラウンドロビンする。Latency sensitivityを0にすると1番早いところにずっとつなぎ続ける。
image.png

Route -> パスベースルーティングの設定（受信プロトコル、キャッシング等）
image.png

カスタムドメイン

Rules Engine

ルールベースで処理が可能。App GWのRewriteみたいな感じ。
GlobalサービスなのでGeoのルールが使える。
image.png

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?