仮想アプライアンス担当者向け Azure ネットワーク/azure network that focus on network virtual appliance

Azure 上で仮想アプライアンスを初めて触る人向けの情報をまとめました

Transcript

1. 仮想アプライアンス担当者向け Azure ネットワーク
2. 自己紹介 @kongou_ae • https://blog.aimless.jp • Azure と Azure Stack Hub を担当 • プリセールスから保守運用までの全てのフェーズを技術支援 • IaaS と Network、Hybrid Cloud が得意分野。PaaS もたしなんでます • Microsoft MVP for Microsoft Azure（2019/05~）
3. 本日のセッションの目的 Azure に仮想アプライアンスを導入する際に必要となる知識を共有 • 基本的なネットワークサービス • 上記の簡単なデモ • ルーティング • サーバの外部公開 • 冗長化
4. 本日のセッションのゴール その１ Azure の基本的なネットワークサービスの概要を知る • ドキュメントに出てくるサービスの意味が分かる • リソースを作るときに出てくるサービスの意味が分かる
5. 本日のセッションのゴール その２ 「Azure に仮想アプライアンスを導入できるかも？」な自信を得る • ベンダのドキュメントを理解できる • ベンダの手順によって作成されたリソースの必要性を理解できる • 通信できない場合にトラブルシュートすべき箇所が分かる
6. お断り • 本セッションは、エンジニアが個人の意見を述べるものです • 所属会社の意見を代表するものではありません
7. 基本的なネットワークサービス
8. Virtual Network(VNet) Azure 内にユーザ専用のネットワーク空間を作る Japan East VNet: 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 • VNet のアドレス空間に大きめのセグメントを割 り当てたうえで、サブネットとして分割する • サブネットのデフォルトゲートウェイは先頭の IP アドレス • VNet のアドレス空間は後から追加できる • VNet のアドレス空間に自前のグローバル IP アド レスを持ち込める。ただしインターネットと通信 する場合は Microsoft 所有のグローバル IP アド レス に送信元 NAT される • マルチキャストは利用できない。ユニキャストの み Internet
9. Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Network Interface(NIC) Virtual Machine と Virtual Network を接続する Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 NIC 1.4/24 Virtual Machine Virtual Machine 2.4/24 3.4/24 3.5/24 NIC NIC • NIC は 個別のリソースとして扱われる • VM ではなく NIC に IP アドレスを設定する。設 定した IP が DHCP で VM に配られる • 1つの NIC に最大256個の IP アドレスを設定でき る • 1つの VM に複数の NIC を接続できる • インスタンスのサイズによって接続できる NIC の 上限が決まっている。複数 NIC ＝ 大きいインス タンスサイズ ＝ 料金が高い Internet
10. Network security group(NSG) VNet を流れる通信をフィルタリングする Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 • IP アドレス、プロトコル、ポート番号の3要素で 通信をフィルタリングできる • ステートフルファイアウォールとして動作する • NIC または サブネットと関連付ける • 1つの NSG を複数の NIC またはサブネットと関連 付けられる • 複数のルールがあった場合、優先度の順で上から 判定処理が行われる • NSG をサブネットに関連付けた場合、同一サブ ネット内の VM の通信は NSG のフィルタリング 対象となる。オンプレの Firewall とはちょっと違 うので注意 Internet
11. Public IP address(PIP) Microsoft 所有のグローバル IP アドレスを借りる Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 • PIP を NIC の IP と関連付けると、インターネッ トから PIP 宛の通信が VM に到達する。また、 NIC の IP からインターネットへの通信が PIP で 送信元 NAT される • PIP を NIC の IP と関連付けたとしても、VNet が DHCP で VM に払い出す IP アドレスはプライ ベート IP アドレスのみ • PIP 経由で届くパケットの宛先は NAT 後のプライ ベート IP アドレス • 「動的割り当て」と「静的割り当て」が存在する Public IP address Internet 2.4/24
12. Route table VNet のルーティングテーブルにスタティックルートを設定する Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 • VNet 内のルーティング動作（後述）を変えたい 場合に利用する • Route table を適用する対象はサブネット • ユーザが Route table に追加したルーティングを User Defined Route: UDR と呼ぶ Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet User 0.0.0.0/0 NVA Subnet①のルーティングテーブル
13. Load balancer ネットワークに内包された負荷分散機能 Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 • ネットワークとサーバが協調することで動作する L4ロードバランサ。箱的なものはない • Basic と Standard がある。高機能な Standard 一 択 • Public IP address への通信を分散する外部 LB と Private IP address への通信を分散する内部 LB が ある • 負荷分散には「送信元 IP、送信元ポート、宛先 IP、 宛先ポート、プロトコルの種類」の5要素から計 算したハッシュ値を利用。セッション単位で分散 • 100 vs 0 分散や優先度による分散は不可 • セッション維持は「送信元 IP アドレス」と「送 信元 IP アドレスとプロトコル」の2択 Internet Load balancer
14. Load balancer ネットワークに内包された負荷分散機能 Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 • 全TCP と 全UDP を負荷分散する HA ポート機能。 NVA で使われる（後述） • ヘルスチェックのパケットは LB の VIP ではなく 168.63.129.16 から届く • LB を経由する通信は送信元 NAT されない。サー バには生の送信元 IP アドレスが届く • 宛先 NAT（LB の VIP を NIC の IP に変換）する かどうかは選べる。Floating IP を有効にすると 宛先 NAT しなくなる • SSL 終端機能はなし。SSL を終端したい場合は L7 LB である Application Gateway を検討する Internet Load balancer
15. VNet Peering VNet 同士を閉域で接続 Japan East 10.0.0.0/16 • ネットワーク的に独立した存在である VNet を接 続できる • 同一リージョン内と別リージョンのどちらも接続 可能 • サブスクリプションをまたいだ Peering も可能 • Peering した VNet 間のみ通信できる。左の構成 図の10.1.0.0/16と10.2.0.0/16は通信できない • 2020年6月現在、VNet Peering した VNet のアド レス空間を追加するためには、一時的に VNet Peering を切断する必要がある 10.1.0.0/16 West US 2 10.2.0.0/16
16. もっと詳しくなりたければ Microsoft Learn に挑戦する • Azure でのネットワーク インフラストラクチャの設計 • Azure 管理者向けの仮想ネットワークの構成と管理 • Azure でハイブリッド ネットワーク アーキテクチャを設計する
17. ルーティング
18. ルーティングの大前提 仮想アプライアンスを利用する場合は2つのルーティングを意識 2つのルーティングが整って初めて通信できる 1. NVA の OS 側のルーティング 2. Azure 側のルーティング
19. NVA の OS 側のルーティング 「どの NIC からパケットを出すか」だけを考える • NVA は複数の NIC を持っている。受信したパケットを通信経路的に正し い NIC から送出するためにルーティングを設定する • VNet 内のパケット転送は VNet に任せる。NVA に設定するルーティン グの Next hop は VNet（サブネットのデフォルトゲートウェイ）にする
20. Azure 側のルーティング VNet だけの場合のルーティング Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet①のルーティングテーブル • デフォルトのルーティング＝システムルート • ネクストホップが Virtual Network の場合、VNet は VM から受信したパケットを宛先 IP の VM に 直接転送する • ネクストホップが Internet の場合、VNet は NIC から受信したパケットを Azure のインターネット 出口に転送する • PIP が紐づくプライベート IP アドレスは、PIP で 送信元 NAT。PIP が紐づかないプライベート IP アドレスは、Azure 都合の適当な IP で送信元 NAT
21. Azure 側のルーティング VPN・Express Route でオンプレと接続した場合のルーティング Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW • オンプレミスと Azure を接続した場合、オンプレ ミスから Azure に向けて広報した経路が自動的に Azure のルーティングテーブルに注入される • Express Route と VPN から同じ経路を注入した 場合、VNet は常に Express Route を優先する Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route Subnet①のルーティングテーブル
22. Azure 側のルーティング 強制トンネリング Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 0.0.0.0/0 VNet GW • オンプレミスから 0.0.0.0/0 を広報することで、 VNet からインターネットへの通信をオンプレミ ス経由にする手法 • 同一 Prefix の場合、VNet はシステムルートより も BGPで学習したルートを優先する • ご利用は計画的に。積極的に使うものではない • 参考：https://docs.microsoft.com/ja- jp/azure/architecture/framework/security/network- security-containment#decide-upon-an-internet- ingressegress-policy Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route Subnet①のルーティングテーブル
23. Azure 側のルーティング VNet Peering した場合のルーティング その１ Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW Default 10.1.0.0/16 VNet Peering • VNet Peering の先のセグメントがルーティング テーブルに注入される • 直結している VNet のセグメントのみがルーティ ングテーブルに注入される。多段 VNet Peering したとしても、注入されるルーティングは隣のみ Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route 10.1.0.0/16 Subnet①のルーティングテーブル
24. Azure 側のルーティング VNet Peering した場合のルーティング その２ Japan East 10.0.0.0/16 Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Internet Source Address Next Hop Default 10.1.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW Default 10.0.0.0/16 VNet Peering • VNet Peering には「Peering 先の VNet GW を 使ってオンプレと通信する」オプションが存在す る（Use remote gateway/Allow gateway transit） • このオプションを有効にした場合、Peering 先の セグメントだけでなくオンプレミスのセグメント もルーティングに注入される Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route 10.1.0.0/16 Subnet③のルーティングテーブル Subnet③ 10.1.1.0/24
25. Azure 側のルーティング ルーティングの優先順位 1. ロンゲストマッチ 2. User defined route 3. BGP（Express Route） 4. BGP（VPN） 5. システムルート
26. 仮想アプライアンスを検討する前に
27. オンプレと全く同じことはできない そもそも仕組みが違うので、オンプレと全く同じことはできない • できないことの最たる例：Ping が数発欠けるレベルの切り替え • オンプレと全く同じことをやりたいのであれば、オンプレをお使いくだ さい
28. まずはネイティブなサービスを検討する 仮想アプライアンスは茨の道 • 誤：物理アプライアンスの移行だから仮想アプライアンスを導入 • 正：物理アプライアンスが提供する機能を Azure のサービスで実現 • Azure Firewall（マネージドなファイアウォール） • Point to Site VPN（Open VPN ベースの Remote Access VPN） • Azure Bastion（メンテナンス用の踏み台サーバ）
29. 茨の道を進む際の心構え
30. 茨の道を進む際の心構え その１ Azure のネットワークは怖くない • Azure のネットワークだって TCP/IP で動いている • 皆様が持っているネットワークの知識はとても役に立つ • 「Azure 固有のクセ」を追加で学ぶだけで OK
31. 茨の道を進む際の心構え その２ Azure のネットワークを Azure 担当に任すと泥沼になるかも • ネットワークに明るい Azure 担当がいるとは限らない • Azure のネットワークの仕組みを理解したうえで、Azure 担当と一緒に Azure のネットワークを設定する • Azure 担当と仮想アプライアンス担当が連携しないと導入は泥沼 に・・・
32. 実践その１ インターネット向け通信
33. 実践その１：インターネット向け通信 とりあえず仮想アプライアンス(NVA)をデプロイしてみる Japan East 10.0.0.0/16 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet • LAN 側が 10.0.2.4、WAN 側が 10.0.3.4 • Subnet①のデフォルトルートは Azure のイン ターネットを向いている • VM-a で 8.8.8.8 に対して名前解決を実施。VM-a から8.8.8.8への通信は、デプロイした NVA を経 由せずにそのままインターネットに出て行ってし まう・・・ Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet①のルーティングテーブル NVA 1.4/24 2.4/24 3.4/24 VM-a 行き 戻り
34. 実践その１：インターネット向け通信 超大事：Route table Japan East 10.0.0.0/16 Internet Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet User 0.0.0.0/0 NVA(10.0.2.4) • Route table を作成してサブネットに割り当てる • Route table 内に 0.0.0.0/0 が NVA(10.0.2.4)に向 かう UDR を設定する • 同一 Prefix の場合、VNet はシステムルートより も UDR を優先する。UDR > BGP > システム • Subnet①のデフォルトルートが 10.0.2.4 を向い たので、VM から8.8.8.8への通信が NVA に向か う・・・はずが、NVA の通信ログに乗ってこない Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet①のルーティングテーブル 1.4/24 2.4/24 3.4/24 NVA VM-a
35. 実践その１：インターネット向け通信 超大事：IP forwarding Japan East 10.0.0.0/16 Internet Source Dest 10.0.1.4 8.8.8.8 • VNet は NIC に割り当てた IPアドレス宛のパケッ トのみを NIC に転送する。そのため、10.0.2.4 な NIC 宛てに宛先が8.8.8.8を発信すると、VNet は このパケットを破棄する • 破棄されないための設定が IP forwarding。有効 化すると、パケットの宛先が NIC に割り当てた IP アドレス以外であっても、そのパケットを NIC に転送する • マーケットプレイスやテンプレートからデプロイ した NVA の場合、構築直後から IP forwarding が有効になっている場合もある Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 VM-a が NVA(10.0.2.4) に発信したパケット 1.4/24 2.4/24 3.4/24 VM-a NVA
36. 実践その１：インターネット向け通信 OS のルーティングを整える Japan East 10.0.0.0/16 Internet Address Next Hop 0.0.0.0/0 10.0.3.1 10.0.2.0/24 Connected 10.0.3.0/24 Connected • 複数 NIC な VM の場合、DHCP でデフォルトゲー トウェイが設定されるのは 1つ目の NIC のみ • 1本目の NIC が 3.4 だったので、初期状態で OS のデフォルトゲートウェイは 3.1 を向いている。 が、パケットは VM-a に戻ってこない・・・ Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 NVA のルーティングテーブル 1.4/24 2.4/24 3.4/24 VM-a NVA Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet③のルーティングテーブル 行き 戻り
37. 実践その１：インターネット向け通信 OS のルーティングを整える Japan East 10.0.0.0/16 Internet Address Next Hop 0.0.0.0/0 10.0.3.1 10.0.2.0/24 Connected 10.0.3.0/24 Connected 10.0.1.0./24 10.0.2.1 • VM-a への戻りのパケットを OS が 2.4 側の NIC から送信するためのルーティングが OS 側に必要 • Subnet②のルーティングテーブルに従って、送信 されたパケットが VM-a に戻る Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 NVA のルーティングテーブル 1.4/24 2.4/24 3.4/24 VM-a NVA Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet②のルーティングテーブル 行き 戻り
38. 実践その２ サブネット間通信 ※ Subnet のルーティングテーブルだけリセット
39. 実践その２：サブネット間通信 VM-a から VM-b への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り • VM-a から VM-b への通信は NVA に向かわず直 接通信してしまう・・・ • Subnet①のルーティングテーブルで、10.0.4.4 宛 ての通信がマッチするルーティングの Next Hop が Virtual Network になっているから Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet①のルーティングテーブル
40. 実践その２：サブネット間通信 VM-a から VM-b への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り • VM-a から VM-b への通信が NVA に向かうよう に、Subnet①に UDR を追加する Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet User 10.0.4.0/24 NVA(10.0.2.4) Subnet①のルーティングテーブル
41. 実践その２：サブネット間通信 VM-a から VM-b への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り Address Next Hop 0.0.0.0/0 10.0.3.1 10.0.2.0/24 Connected 10.0.3.0/24 Connected 10.0.1.0./24 10.0.2.1 10.0.4.0/24 10.0.3.1 NVA のルーティングテーブル • NVA は 10.0.4.4 宛ての通信を 0.0.0.0/0 のルー ティングに従って、10.0.3.1 に転送する • 分かりやすさのために、10.0.4.0/24 宛てのルー ティングを足すのをお勧め • VNet は NVA から受信した 10.0.4.4 宛てのパ ケットを Subnet③の「10.0.0.0/16は VNet」の ルーティングに従って 10.0.4.4 に転送
42. 実践その２：サブネット間通信 VM-a から VM-b への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り • Subnet④のルーティングテーブルが初期のままだ と、10.0.1.4 への戻りのパケットが NVA を経由 せず非対称ルーティングになる・・・ Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet④のルーティングテーブル
43. 実践その２：サブネット間通信 VM-a から VM-b への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り • 戻りの通信が NVA に向かうように UDR を追加す ることで、非対称ルーティングを解消する Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet User 10.0.1.0/24 NVA(10.0.3.4) Subnet④のルーティングテーブル
44. 実践その３ オンプレミスと VNet 間 ※ 全設定をリセット
45. 実践その３：オンプレミスと VNet 間 オンプレから VM-a への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り • Gateway Subnet のルーティングに従って、オン プレミスから 10.0.1.4 宛ての通信は NVA を経由 しない。NVA を経由するように UDR を追加する Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW Gateway Subnet のルーティングテーブル Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW User 10.0.1.0/24 10.0.3.4 修正後のGateway Subnet のルーティングテーブル
46. 実践その３：オンプレミスと VNet 間 オンプレから VM-a への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route Address Next Hop 0.0.0.0/0 10.0.3.1 10.0.2.0/24 Connected 10.0.3.0/24 Connected 10.0.1.0./24 10.0.2.1 広報したアドレス 10.0.3.1 NVA のルーティングテーブル • NVA のルーティングテーブルに、VM-a とオン プレミス用のエントリを追加する
47. 実践その３：オンプレミスと VNet 間 オンプレから VM-a への通信を NVA で制御してみる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Gateway Subnet 10.0.5.0/24 IPsec VPN Express Route • Subnet ①のルーティングに従って、オンプレミ スから 10.0.1.4 の戻りは NVA を経由しない。 NVA を経由するように UDR を追加する Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW Subnet①のルーティングテーブル Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet VNet GW 広報したアドレス VNet GW User 広報したアドレス NVA(10.1.2.4) 修正後のSubnet①のルーティングテーブル
48. 実践その４ VNet Peering 越し ※ 全設定をリセット
49. Japan East 10.2.0.0/16 10.1.0.0/16 実践その４：VNet Peering 越し VM-a から VM-b への通信を NVA で制御してみる 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.1.2.0/24 Subnet③ 10.1.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Subnet④ 10.2.4.0/24 4.4/24 VM-b • 多段 VNet Peering の制限によって、10.2.0.0/16 のルーティングは注入されない。その結果 VM-a から VM-b への通信は Azure のインターネット に向かってしまう・・・ Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Default 10.1.0.0/16 VNet Peeing Subnet①のルーティングテーブル
50. Japan East 10.2.0.0/16 10.1.0.0/16 実践その４：VNet Peering 越し VM-a から VM-b への通信を NVA で制御してみる 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.1.2.0/24 Subnet③ 10.1.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Subnet④ 10.2.4.0/24 4.4/24 VM-b • 多段 VNet の制限によって VM-a と VM-b は直接 通信できない • そこで、隣の VNet に設置されている NVA に向 けた UDR を追加する Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Default 10.1.0.0/16 VNet Peeing User 10.2.0.0/16 NVA(10.1.2.4) 修正後のSubnet①のルーティングテーブル
51. Japan East 10.2.0.0/16 10.1.0.0/16 実践その４：VNet Peering 越し VM-a から VM-b への通信を NVA で制御してみる 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.1.2.0/24 Subnet③ 10.1.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Subnet④ 10.2.4.0/24 4.4/24 VM-b Address Next Hop 0.0.0.0/0 10.0.3.1 10.0.2.0/24 Connected 10.0.3.0/24 Connected 10.2.0.0/16 10.0.3.1 10.0.0.0/16 10.0.2.1 NVA のルーティングテーブル • 受け取ったパケットを VM-b に転送するために、 NVA のルーティングテーブルに 10.2.0.0/16 を追 加する • 同様に、戻り用の 10.0.0.0/16 のルーティングも NVA に追加する
52. Japan East 10.2.0.0/16 10.1.0.0/16 実践その４：VNet Peering 越し VM-a から VM-b への通信を NVA で制御してみる 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.1.2.0/24 Subnet③ 10.1.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Subnet④ 10.2.4.0/24 4.4/24 VM-b • Subnet③のルーティングテーブルには、隣の VNet ルーティングが注入されている • NVA が 10.1.3.1 宛てに発信したパケットは、 Subnet③のルーティングに従って、VM-b に転送 される Source Address Next Hop Default 10.1.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Default 10.0.0.0/16 VNet Peeing Default 10.2.0.0/16 VNet Peeing Subnet②と③のルーティングテーブル
53. Japan East 10.2.0.0/16 10.1.0.0/16 実践その４：VNet Peering 越し VM-a から VM-b への通信を NVA で制御してみる 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.1.2.0/24 Subnet③ 10.1.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Subnet④ 10.2.4.0/24 4.4/24 VM-b • 何もしないと、VM-b から VM-a への戻りは Azure のインターネットに向かってしまう • VM-a と同様に、隣の VNet に設置されている NVA 向けの UDR を追加する • 戻りのための NVA のルーティングは追加済みな ので、戻りのパケットは無事に VM-a に届く Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Default 10.1.0.0/16 VNet Peeing User 10.0.0.0/16 NVA(10.1.3.4) 修正後のSubnet④のルーティングテーブル
54. サーバの外部公開
55. そもそも NVA 経由で外部公開する必要があるか まずは VM に Public IP Address を割り当てる方式を検討する • オンプレでサーバを外部公開＝ Firewall で Static NAT が必須 • クラウドの場合、Firewall で Static NAT は必須条件ではない • PIP や Public LB を使って Static NAT ができる • NSG を使って サーバ単位で Inbound の通信を限定できる • サーバ単位で WAF や DDoS 対策のサービスを使える
56. そもそも NVA 経由で外部公開する必要があるか 異なる Route table を使い、サブネット単位で NVA の利用を制御 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 Subnet④ 10.0.4.0/24 1.4/24 2.4/24 3.4/24 4.4/24 VM-a VM-b NVA 行き 戻り • VM-a からインターネットへの通信は NVA 経由。 VM に PIP をアサインしても PIP 経由の Inbound は非対称ルーティングになり通信できない Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet User 0.0.0.0/0 NVA(10.0.2.4) Subnet①のルーティングテーブル • VM-b からインターネットへの通信は直接アクセ ス。NVA を経由しない。Inbound も直接 Source Address Next Hop Default 10.0.0.0/16 Virtual Network Default 0.0.0.0/0 Internet Subnet④のルーティングテーブル
57. NVA 経由で外部公開する際の選択肢 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 1.1.1.1/32 3.5/24 2.2.2.2/32 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 1.1.1.1/32 2.2.2.2/32 ①NVA に 複数の PIP を関連付ける ②NVA に 複数 PIP の LB を関連付ける
58. 外部公開①：複数 Public IP Address NVA に到達する前に Static NAT が実施される Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Source Destination Client 2.2.2.2 PIP 通過前のパケット Source Destination Client 1.0.3.5 NVA に到達するパケット • NVA のポリシーでは、PIP を関連付けた NIC の プライベート IP アドレスを VIP のように使う • PIP のグローバル IP アドレスはポリシーで利用不 可 Source Destination TransSource TransDest Client 10.0.3.5 Origin 10.0.1.4 NVA のポリシー例 1.1.1.1/32 3.5/24 2.2.2.2/32
59. 外部公開①：Public IP Address Inbound と Outbound のグローバル IP アドレスを揃えられる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 VM-a NVA 行き 戻り • NVA で Inbound の PIP を関連付けた NIC のプラ イベート IP アドレスに SNAT する • Azure は 送信元 IP アドレスが NIC のプライベー ト IP アドレスになっている通信を、紐づく PIP のグローバル IP アドレスに SNAT する Source Destination T-Source T-Dest 10.0.1.4 Any 10.0.3.5 Any NVA のポリシー例 Source Destination 2.2.2.2 8.8.8.8 PIP 通過後のパケット Source Destination 10.0.3.5 8.8.8.8 NVA が発信したパケット 3.4/24 1.1.1.1/32 3.5/24 2.2.2.2/32
60. 外部公開②：Standard Loadbalancer Floating IP を使うと、Inbound がオンプレっぽい動作になる Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り Source Destination Client 2.2.2.2 LB 通過前のパケット Source Destination Client 2.2.2.2 NVA に到達するパケット • Floating IP を有効にすると LB は DNAT しない • 宛先が LB の PIP のパケットが NVA に届くので、 NVA の Firewall ルールで PIP のグローバル IP ア ドレスを VIP のように扱える Source Destination TransSource TransDest Client 2.2.2.2 Origin 10.0.1.4 NVA のポリシー例 1.1.1.1/32 2.2.2.2/32
61. 外部公開②：Standard Loadbalancer Inbound と Outbound のグローバル IP アドレスを揃えられない Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 1.4/24 2.4/24 3.4/24 VM-a NVA 行き 戻り 1.1.1.1/32 2.2.2.2/32 • NVA で PIP のグローバル IP アドレスに SNAT し てはならない。プライベート IP アドレスに SNAT Source Destination T-Source T-Dest 10.0.1.4 Any 10.0.3.4 Any NVA のポリシー例 Source Destination 1.1.1.1 or 2.2.2.2 8.8.8.8 LB 通過後のパケット Source Destination 10.0.3.4 8.8.8.8 NVA が発信したパケット • LB は LB の いずれかの PIP を利用して SNAT • PIP 方式のように Inbound と Outbound のグ ローバル IP アドレスを揃えられない
62. 冗長化
63. 冗長化を理解するための前提 オンプレ流の Active/Standby な冗長化はクラウドにあわない • クラウドはスケールアウトで可用性を高める Active/Active な世界 • 使った分だけ従量課金 ＝トラフィックを処理していないにも関わらずリ ソースを確保する Standby 機は無駄 • Active/Standby を実現する機能を実装するモチベーションがなさそう
64. 冗長化を理解するための前提 NVA 内部だけで冗長化しても無駄 • ユニキャストな仕組みを使って OS 内部に VIP を作ったとしても、クラ ウドのネットワークはその VIP を認識できない • クラウドのネットワークから見えるものは、クラウドのネットワークが NIC に割り当てた IP アドレスのみ
65. 冗長化を理解するための前提 NVA がクラウドのネットワークの Active/Standby を制御する • 通常時はクラウドのネットワークが Active 機にのみトラフィックを転送 するように設計する • NVA の系切り替えの処理として、クラウドのネットワークの設定を書き 換えてトラフィックが Standby 機に転送されるようにする • クラウドの設定変更には時間がかかる。ゆえに Ping 数発で切り替えは難 しい
66. 冗長化を理解するための前提 NVA 用の Azure AD アカウント（Service Principle）が必要 • NVA はクラウドのネットワークの設定を変更するために API を叩く • API を叩くためには AAD の認証を受けなければならない。この時に利用 するアカウントが Service Principle • Service Principle にはパスワードの有効期限が存在する。期限が切れると AAD の認証が失敗するので、クラウドのネットワークの設定を変更でき なくなる・・・無期限にする or 定期更新を忘れない
67. 冗長化を理解するための前提 Service Principle への権限付与を忘れずに • クラウドのネットワークの設定を変更するためには、Service Principle に リソースの設定を変更できる権限を付与する必要がある • 権限が不足している場合、クラウドのネットワークの設定変更は失敗す る＝障害時に系が切り替わらない・・・
68. 冗長化の例
69. 冗長化方式１：PIP 付け替え & UDR 書き換え Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 • OS 側の系切り替え • Azure の設定変更 1.4/24 Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.4) Subnet①のルーティングテーブル Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.5) Subnet①のルーティングテーブル 通常時 障害時 NVA#2
70. 冗長化方式１： PIP 付け替え & UDR 書き換え サンプル：FortiOS の設定 Service Principle 設定を変更する Azure リソース config system sdn-connector edit "AZConnector" set type azure set tenant-id "<tenant_ID>" set subscription-id "<subscription ID>" set resource-group "<resource group name>" set client-id "<client ID>" set client-secret <client secret key> config system sdn-connector config nic edit "FortiGate-A-NIC1" config ip edit "ipconfig1" set public-ip "FGTAPClusterPublicIP" next (snip) config route-table edit "FortiGateDefaultAPRouteTable" config route edit "toDefault" set next-hop "10.0.2.4" next
71. 冗長化方式１： PIP 付け替え & UDR 書き換え サンプル：FortiOS の設定 設定を変更する Azure リソース config system sdn-connector config nic edit "FortiGate-A-NIC1" config ip edit "ipconfig1" set public-ip "FGTAPClusterPublicIP" next (snip) config route-table edit “FGTDefaultAPRouteTable" config route edit "toDefault" set next-hop "10.0.2.4" next • config nic • 自分が Active 機になったら、FortiGate-A-NIC1 という NIC の ipconfig1 というプライベート IP アドレスに FGTAPClusterPublicIP という PIP を関連付けろ • 停止した 2号機の NIC に関連づいていた PIP が外れて、新た に Active になった1号機に PIP が関連づく。その結果、 Active な1号機にトラフィックがくるようになる • config route • 自分が Active 機になったときに、FGTDefaultAPRouteTable という route table の toDefault というルーティングの Next hop を 10.0.2.4 に書き換えろ • 停止した2号機（10.0.2.5）に向いていた UDR が書き換わる ことで、Active な1号機にトラフィックが来るようになる
72. 冗長化方式２：PIP 付け替え & Next hop の IP 付け替え Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.6) Subnet①のルーティングテーブル Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.6) Subnet①のルーティングテーブル 2.6/24 2.6/24 • OS 側の系切り替え • Azure の設定変更 通常時 障害時
73. 冗長化方式３： Standard LB & UDR 書き換え Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.4) Subnet①のルーティングテーブル Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.5) Subnet①のルーティングテーブル ヘルスチェックに 応答する ヘルスチェックに 応答しない ヘルスチェックに 応答する • OS 側の系切り替え • Azure の設定変更 通常時 障害時
74. 冗長化方式４： 上下 Standard LB Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Japan East 10.0.0.0/16 Internet Subnet① 10.0.1.0/24 Subnet② 10.0.2.0/24 Subnet③ 10.0.3.0/24 2.4/24 3.4/24 VM-a NVA#1 2.5/24 3.5/24 NVA#2 1.4/24 Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.10) Subnet①のルーティングテーブル Address Next Hop 10.0.0.0/16 Virtual Network 0.0.0.0/0 NVA(10.0.2.10) Subnet①のルーティングテーブル ヘルスチェックに 応答する ヘルスチェックに 応答しない ヘルスチェックに 応答する 2.10/24 2.10/24 • OS 側の系切り替え 通常時 障害時
75. まとめ
76. 仮想アプライアンスを検討することになった貴方へ 本当に仮想アプライアンスが必要なのかを再考する • そもそもオンプレと全く同じことは実現できない。 • 単純移行もできない。Azure にあった構成・設定に変更必須 • NVA を導入すると VNet の設定は複雑になる • Azure のサービスで要件を実現する方法を検討する
77. 仮想アプライアンスを導入することになった貴方へ OS のルーティングと VNet のルーティングを意識する • 仮想アプライアンスの設定だけを見ていると動かない NVA が完成する • 「Azure 担当の代わりに VNet のルーティングを設計する」くらいのつ もりが大事 • User defined route を駆使して、通信要件を達成する
78. 仮想アプライアンスを導入することになった貴方へ クラウドのネットワークと連携した HA 構成を理解する • オンプレミスとは HA の実装が異なる • Azure 側の構成を熟知したうえで、NVA の HA 設定を実装する • 導入時に切り替え試験を忘れない
79. 参考資料 • 仮想ネットワーク トラフィックのルーティング • サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会 • Ananta: Azure を支えるステートフル L4 ロードバランサー • Azure VM の外部接続 (SNAT) オプション まとめ • ネットワーク仮想アプライアンス (NVA) 経由で通信できない時のチェックポイント • パブリッククラウドと仮想アプライアンス型ファイアウォール • PaloAlto on Azure を Active/Passive 構成で導入する • Active/Passive な FortiGate を Azure 上にデプロイする