[Day5] Azure のネットワークがさっぱり分からん


# Microsoft Azure Tech Advent Calendar 2018 の 5 日目です。

今回は、インフラ野郎が大好きな Azure のネットワークについて整理してみたいと思います。

 

4 種類の Azure ネットワーク

Azure  のネットワークは、大きく 4 種類に分かれます。

  • Private IP (Azure VNET) のネットワーク: VNET 内に展開される VM 等
  • Public IP (VNET 外) のネットワーク: VNET 外に配置される各種 PaaS や、VM の Public IP 等
  • Azure 基板側のネットワーク: バックボーン ネットワークや、物理サーバー用 (ユーザーからは見えない部分)
  • Azure 外に存在するネットワーク: Azure DNS や Traffic Manager、CDN、FrontDoor 等

ざっくり図にすると、こんな感じになります。

# よくある誤解

たまに Azure Storage や SQL Database 等の PaaS に対して VPN 接続したいという話を聞きますが、VPN 接続出来るのは VNET のみですので、Public IP の世界に接続したい場合には ExpressRoute の Microsoft Peering が必要です。(もしくは、App Service Environment や SQL Database Managed Instance のように VNET 内に専用のインスタンスを建てられる上位プランを使用する必要があります。)

また、Azure のサービスであっても、Azure データセンター外の Public IP からサービスを提供する Azure DNS, Traffic Manager, CDN, FrontDoor 等のサービスについては、VPN でも ExpressRoute 経由でもアクセスすることが出来ません。(これらは Internet 経由のアクセスを前提としたサービスなので、閉域環境で使う事を想定されていません) くわえて、内部的にこれらを使っているもの (例えば Azure Portal とか) に対しても、ExpressRoute 経由で閉域だけで接続するといったことは出来ませんので気をつけましょう。

物理的なネットワーク構成

Microsoft が世界中に保有するバックボーン ネットワークや、Azure データセンター内のネットワーク アーキテクチャについては、多少情報が古いものも混じってますが以下が参考になります。使用しているスイッチやルーターの名称まで記載されているものもあるので、インフラ野郎は隅から隅まで目を通すと興味深いかと思います。

# 以下、上記から拝借。

Microsoft 所有の Global Network の全体像。水色が自社所有、濃い青が借用、点線が計画中のもの。

 

Azure の各リージョンは Microsoft の Global Network (WAN) に接続され、世界中の Edge から Internet や ExpressRoute で接続されます。

 

各リージョンには複数のデータセンターがあり、RNG (Regional Network Gateway) で束ねられています。

 

データセンター内は、Quantum 10 (Q10) のアーキテクチャが採用され、以下の様な機器が使用されているらしいです。

VNET の仕組み

IaaS ユーザーの方からすると、先のような概念的な話よりも、Azure VNET の方が身近かと思います。

が、VNET の仕組みをきちんと理解した上で使っている人は少ないのではないかと思うので改めて。

 

Azure では、数百万台規模の物理サーバーが世界中に存在しています。VM はリージョン内のどこかの物理サーバー上でホストされますが、同一 VNET 内の VM 間の通信はどのように行われているかを考えるには、Azure 基板側のアンダーレイ ネットワークと、VNET 側のオーバーレイ ネットワークを意識する必要があります。

ここでは、以下の図のように 2 台の物理サーバー上に 2 つの VNET (A, B) が存在している場合を考えます。VNET A の 10.0.0.4 -> 10.0.0.5 宛に通信する場合は、物理サーバー上で一度カプセル化されてアンダーレイ ネットワーク上でルーティングされます。

# VNET A と B は論理的に分離されているので、別 VNET に同一の Private IP を持つ VM が乗っていても問題は起きません。

VFP の仕組み

こうした Azure の SDN を支えているのが、Hyper-V の Virtual Switch で動作する VFP (Virtual Filtering Platform) です。

詳しいことは Windows Server 2016 等の HNV 系のドキュメントや、Microsoft Research の論文を読むと理解が深まります。

論文内の画像を抜粋しつつ、かいつまんで説明すると、Hyper-V の仮想スイッチ上でフィルター ドライバーの用に振る舞い、Ingress / Egress のトラフィックに対しての処理を行うのが VFP です。

VFP ではどのような処理が行われるかというと、以下の図のように大きく 4 種類の処理があります。

  • VNET: 前述のアンダーレイ・オーバーレイ ネットワーク間のカプセル化 (encap / decap) を担います。
  • NAT: Public IP で受信したパケットを VNET 内の Private IP に変換したり、LB 経由の通信の NAT を担います。
  • ACLs: Network Security Group (NSG) の機能に該当するものです。
  • Metering: 各種メトリックのデータ取得を担います。課金メーターもこのレイヤーで行っています。

# ちなみに、上図の略称はそれぞれ以下の通り

  • PA: Physical Address (基盤側の IP アドレス)
  • CA: Customer Address (VNET 内の Private IP アドレス)
  • VIP: Virtual IP (Public IP のこと)
  • DIP: Dynamic IP (Private IP のこと)

 

VNET 内の通信を行う場合

では、もう少し噛み砕いて見てみましょう。(Metering は通信に直接関係しないので省略)

10.0.0.4 の VM からパケットが出て行く際は、10.0.0.4 -> 10.0.0.5 の通信として NIC および Subnet のNSG 送信規則で評価が行われます。その後カプセル化が行われ、送信元の物理サーバーの PA -> 宛先 IP の VM をホストする物理サーバーの PA (192.0.2.1 -> 192.0.2.2) のように Azure 基盤のネットワーク上をルーティングされます。

受信側ではカプセル化を解除するとともに、そのパケットが自身のホストするどの VM / VNET 宛なのかを判断し、Subnet および NIC の NSG で受信規則に基づいて評価を行います。

Azure VM 間で通信をする際、通常ここまで意識はしませんが、実は裏では VFP が頑張ってくれています。

 

VM の Public IP 宛の通信の場合 (LB 宛もほぼ同等)

続いて、Azure VM の Public IP 宛に通信が来た場合を考えてみます。

Internet 側からパケットが届きますが、VFP は Public IP と Private IP の対応を知っているため、宛先 IP を DNAT して VM に渡します。

反対に、戻りのパケットでは SNAT をして Src IP を Public IP に書き換えてから出ていきます。

なお、NSG の評価は受信方向の通信であれば Public IP や LB の NAT 処理後、送信方向の通信であれば NAT 処理前に行われるので、VM の Private IP のまま評価されます。

# たまに、Public IP 宛に届いた通信を NSG でブロックしようとする人がいますが、そんなことはできません。

 

UDR を設定した場合の挙動

次に、仮想アプライアンス (NVA) を構築する場合などで、全ての宛先 (0.0.0.0/0) 宛の通信を NVA へ向けるような UDR を設定した場合を考えてみます。

前述の 10.0.0.4 -> 10.0.0.5 宛の通信と似ていますが、送信元の物理サーバー上でカプセル化が行われる際、UDR を向けた NVA がホストされている物理サーバーの PA 宛として Azure 基盤側でルーティングが行われます。

この辺りは SDN 特有で、慣れないと混乱しますが、分からなくなったら落ち着いて図にするのが吉です。

Azure ネットワーク、ムズカシイネ。

 

その他、Azure のネットワークを理解するうえで参考になる資料


NSG / UDR の定義を CSV から生成する方法


NSG とか UDR に定義を追加するとき、CSV から一括でインポートしたいことありますよね。

昔作ったスクリプトが残ってたので、GitHub で適当に公開しておきました。

 

ご自由にどうぞ。

Add-AzureRmNetworkSecurityRuleConfigFromCSV.ps1

Add-AzureRmRouteConfigFromCSV.ps1


削除できなくなった Azure リソースを頑張って消す方法


Azure を使っていると、たまに設定ミス等でリソースが削除できない状態に陥ることがあります。

そんな時は、ひとまず以下を試してみると消せる場合があるのでご参考までにどうぞ。(必ず消せるとは限りません)

1. Azure PowerShell で正しい値に設定しなおす

誤った設定を流し込んで、リソースの状態が「失敗」や「Provisioning State: Failed」 になっている場合、Azure PowerShell 等で正しい構成情報で上書きすることで解消できることが多々あります。

一度 Azure PowerShell で既存の設定を Get して、誤ったパラメーターを修正したのち、再度 Set してみましょう。

# 誤った設定をして、「失敗」状態になった例

# Azure PowerShell で設定を修正する例 (ExpressRoute の接続リソースの例)

# 既存の設定を取得
$Connection = Get-AzureRmVirtualNetworkGatewayConnection -Name shuda1120 -ResourceGroupName shudaExR

# 誤った設定箇所を修正
$Connection.Peer.Id = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/ExR/providers/Microsoft.Network/expressRouteCircuits/MyCircuit"

# 修正後の設定で上書き
Set-AzureRmVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $Connection

2. Resource Explorer で正しい値に設定しなおす

Azure PowerShell と同じような話ですが、Resource Explorer (https://resources.azure.com) でも JSON の書き換えが出来たりします。

左のメニューから対象のサブスクリプション内のリソースを辿っていって、対象のリソースの [Edit] から書き換えて [PUT] しましょう。

# Resource Explorer から修正する例

3. JSON テンプレートの完全デプロイを試す

Azure は、JSON テンプレートからリソースをデプロイできますが、増分 (差分) モードと完全モードがあるのをご存知でしょうか。

完全デプロイをすると、対象のリソース グループ内を JSON テンプレートの内容で完全に上書きすることができます。

つまり、既存のリソースは削除されるので、それを利用して無理やり消すという小技が使える場合があります。

(不用意に使うと、他のリソースが消えるので十分注意しましょう)

4. サポートに依頼する

パッと思いつくのは以上 3 点なので、ダメそうであればサポートに依頼しましょう。

ただし、サポートの中の人もお客様環境を直接操作したりできる権限は基本的に持っていないので (というか、持っていたら色々マズい)

修正が完了するにはエスカレーション等で少なくとも数日はかかります。気長に待ちましょう。


Windows Server 2019 で Windows Admin Center のポップアップを無効化する


Windows Server 2019 の起動時 (というか、サーバー マネージャーの起動時) に Windows Admin Center (WAC) のポップアップ [Windows Admin Center でのサーバー管理を試してみる] が出ますが、以下のレジストリで無効化できそうでした。

HKLM\SOFTWARE\Microsoft\ServerManager\DoNotPopWACConsoleAtSMLaunch

  • 0: サーバー マネージャー起動時に WAC のポップアップを表示 (既定)
  • 1: サーバー マネージャー起動時に WAC のポップアップを無効化

そもそもサーバー マネージャー自体を毎回起動させたくない場合は以下も一緒に設定しましょう。

HKLM\SOFTWARE\Microsoft\ServerManager\DoNotOpenServerManagerAtLogon

  • 0: ログイン時にサーバー マネージャーを起動 (既定)
  • 1: ログイン時にサーバー マネージャーを起動しない

 

Procmon で RegSetValue してるのを探すだけだから簡単ですね。

 

コマンドでやりたい場合は以下でいけるかな。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager" /v DoNotPopWACConsoleAtSMLaunch /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager" /v DoNotOpenServerManagerAtLogon /t REG_DWORD /d 1 /f

 

ちなみに、Windows Admin Center 自体は非常に良いものなので、ぜひ使ってみてくださいな。

指崎さんのスライドがわかりやすいのでオススメです。

 

 

 

 


ログオンの監査の話


クラウドの時代になって、ポチポチするだけで Public IP を持った VM が手軽に作れる時代になりましたが、その一方で Public IP で直接アクセスできるの怖いなぁと思う話を先日きいたので、注意喚起の意味も込めてブログのネタにしてみるなど。

 

以下は至って普通の Windows VM ですが、[Event Viewer] – [Windows Logs] – [Security] から、”Audit Failure” でフィルターすると、AdminXXX とか、UserXXX とか、SUPPORT とか、ありがちなユーザー名で謎の IP からログインが多数試行されてたりします。

 

Details の中身をよく見てみると、どういうユーザー名で (TargetUserName)、どういうアクセス方法で (LogonType)、どこから (IpAddress) アクセスがあったかがわかります。詳しくは以下のドキュメントとか見てもらえればと思いますが、RDP の場合には LogonType は 10 とかで記録されて、その他ネットワーク越しのアクセスだと 3 とかが多いかな。

で、アクセス元の IP を適当に調べてみると、上記の例ではロシアからのアクセスで、既に複数の Abuse (迷惑行為の報告) が上がってるみたいですね。

まあ、Failure なのでログオンされてはいないはずですが、調べてみると結構な数のログインが試行されているので、初めて見たときは結構な衝撃を受けると思います。脆弱なユーザー名・パスワードを使ってると、デプロイして数時間や数日で乗っ取られて攻撃元にされたり、その結果として自分自身が加害者側として報告される可能性もあるので、Firewall で特定の IP 以外からはブロックするとか、VPN 越しに Private IP でしか接続できなくするとか、オンプレ・クラウド問わず気を付けましょう。

あと、逆に攻撃された場合は当該 IP の管理者へも報告するといいと思います。(Microsoft 所有の IP の場合は以下から報告できます)

クラウドだと Azure も AWS も Public IP Range は公開されてますし、それに限らず我が家のコンテナ データセンターで使ってるグローバル IP アドレスなんかも普通にログイン試行されてる形跡があったりします。

手軽に検証環境とか作っちゃいがちですけど、IaaS の場合は OS やミドルウェアの管理はユーザーの責任範囲になるので、ユーザーとパスワードの管理をはじめ、セキュリティ対策には十分に気を付けましょうね、というお話でした。


Win 10 で共有フォルダーにアクセスできなかった件


新しい NAS を買ったので、さっそく階層化ボリュームを構成してつなごうと思ったら、久々にこのエラーに遭遇したので対処策をメモっておきます。

組織のセキュリティ ポリシーによって非認証のゲスト アクセスがブロックされているため、この共有フォルダーにアクセスできません。これらのポリシーは、ネットワーク上の安全でないデバイスや悪意のあるデバイスから PC を保護するのに役立ちます。

Webで調べると、AllowInsecureGuestAuth のレジストリを書き換えれば繋がるとか雑な対処策がたくさん書かれていますが、これはセキュリティ上よろしくない。

 

というのも、この現象が出るのは Windows10 の Fall Creators Update (1709) でセキュリティ上の理由によって明示的に無効化された経緯があるから。

なので、匿名認証にならないように (PC\LocalUser -> NAS\NASUser とかアクセスした際に勝手に匿名認証にならないように) ちゃんと NAS と PC のユーザー管理をしましょうというお話。

  • PC と NAS に同じユーザー・パスワードのアカウントを作る
  • PC と NAS でユーザー・パスワードが違う場合は、[資格情報マネージャー] – [Windows 資格情報]に認証情報を登録する

 

SMB 周りはバージョンによって暗号化の有無とかも違うし、SMB1 は wannacry の件もあったし、古いものはさっさと駆逐しましょう。マジで。