クラシック環境のネットワーク構成変更


Azure クラシック ポータルのリタイアが続きますが、10/5 からはネットワークも新ポータルのみになりました。

クラシック環境のネットワークは xml で定義されているので、マルチサイトと VPN を張る際に編集が必要になったりしますが、私の知る限り新ポータルに xml のエクスポート・インポートの UI がありませんので、Azure PowerShell でやる方法をメモっておきます。

# エクスポート
Get-AzureVNetConfig -ExportToFile "<XMLファイルのパス>"

# インポート
Set-AzureVNetConfig -ConfigurationPath "<XMLファイルのパス>"

Application Gateway の証明書更新


Application Gateway の証明書更新の手順が公式のドキュメントとして用意されていないので、中の人として GitHub に PR を投げたにもかかわらず 3 カ月たっても Approve してもらえないんで、こっちに手順だけメモっておきます。

https://github.com/ShuheiUda/azure-docs.ja-jp/blob/66c94ab4ff9ffee63bfc5fa90b03f6de3513c250/articles/application-gateway/application-gateway-update-ssl-certificate-arm.md

 

Azure PowerShell から以下のような感じでサクっとやりましょう。

# Azure アカウントにログインします。
Login-AzureRmAccount
# アカウントのサブスクリプションを確認します。
Get-AzureRmSubscription

# 使用する Azure サブスクリプションを選択します。
Select-AzureRmSubscription -Subscriptionid "サブスクリプション ID"

# 既存の Application Gateway の構成情報を取得します。
$appgw = Get-AzureRmApplicationGateway -Name "<Application Gateway 名>" -ResourceGroupName "<リソース グループ名>"

# 既存の証明書名と同一の名称で、更新する証明書ファイルを設定します。
$appgw = Set-AzureRmApplicationGatewaySslCertificate -Name "existing certificate name" -ApplicationGateway $appgw -CertificateFile "<更新する証明書のフルパス>" -Password "<証明書のパスワード>"

# Set-AzureRmApplicationGateway コマンドを使用して、新しい構成を保存します。
Set-AzureRmApplicationGateway -ApplicationGateway $appgw

Intel NUC の BIOS 更新でハマった件


みんな大好き Intel マザーで AMT の脆弱性が報告されてるので、今更ですが夏休みのタイミングで我が家の機材一式の BIOS を更新。

  • DQ57TM
  • DQ77MK
  • DC53427HYE x4
  • NUC5I5MYHE x4

我が家は全部 vPro / AMT 対応機なので、SA-00075 はモロに影響ありな訳です。

インテル マネージャビリティー・ファームウェアの重大な脆弱性について
https://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/intel-amt-vulnerability-announcement.html

Intel Active Management Technology, Intel Small Business Technology, and Intel Standard Manageability Escalation of Privilege
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr&_ga=2.100311194.504127720.1505920245-97146741.1505920245

2017/05 以降にリリースされた最新版の BIOS を拾ってきて、readme に Intel ME の更新ってなってるのを確認して地道に適用するだけ。

 

ただ、DC53427HYE だけは F7 で BIOS 更新に失敗するし、exe 版の Express BIOS update もエラーだの失敗してるのに Success とか表示するしで酷い目にあったのでメモ。

黄色いジャンパーを抜いて、BIOS 復元モードで解決。

https://downloadcenter.intel.com/download/26795/NUCs-BIOS-Update-RKPPT10H-86A-?product=74483

https://downloadmirror.intel.com/26795/eng/NUC-BIOS-Update-Readme.pdf

https://www.intel.com/content/www/us/en/support/boards-and-kits/000005532.html

ひと段落したら完成間近のコンテナに移設しましょうかね。


RDCMan でサムネイル画面のまま操作できるようにする


みんな大好き RDCMan でサムネイル画面のまま操作できないもんかと思って調べてみたら、ちゃんと出来るみたいだったのでメモ。

サムネイル画面のサイズは [Tools] – [Client Area] から [Thumbnail Unit Size] で設定。4K モニターなら FullHD で 4 画面とか、もう少し小さくて 9 画面でもいいかも。

 

肝心のサムネイル画面のまま操作する設定は、グループのプロパティとかで、[Allow thumbnail session interaction] のチェックを入れるだけ。

 

というわけで、無事できました。これは楽だ。


Test-AzureRmTraffic を公開しました


Azure の便利ツールをまた一つ公開しました。

Test-AzureRmTraffic
https://github.com/ShuheiUda/test-azurermtraffic

NSG で通信を絞ったときに、目視で個々のルールを確認して許可・拒否判断するのは非効率なので、EffectiveNSG をベースに “NSG の設定上” どう判断されるかをチェックしてくれるツールです。

例えば以下のようなシナリオの調査で使ってください

  • NSG で通信を絞った結果、許可したつもりの通信が通らない
  • 通信不可の原因が NSG なのか、VM 内の問題かを切り分けたい

使用例

PS> .\Test-AzureRmTraffic.ps1 -VMName shudaVM -SourceIPv4Address 192.168.0.4 -SourcePort 80 -DestinationIPv4Address 10.0.0.5 -DestinationPort 80 -Protocol TCP -Direction Inbound

(許可の場合)
Access : Allow
Priority : 65000
Name : defaultSecurityRules/AllowVnetInBound
Protocol : All
SourceAddressPrefix : VirtualNetwork
SourcePortRange : 0-65535
DestinationAddressPrefix : VirtualNetwork
DestinationPortRange : 0-65535
Direction : Inbound

(拒否の場合)
Access : Deny
Priority : 65500
Name : defaultSecurityRules/DenyAllInBound
Protocol : All
SourceAddressPrefix : 0.0.0.0/0
SourcePortRange : 0-65535
DestinationAddressPrefix : 0.0.0.0/0
DestinationPortRange : 0-65535
Direction : Inbound

なお、実際にパケットを投げているわけではないので、NSG 上は許可されているのに実際には通信ができないといった場合は、OS 内の Firewall なり、オンプレの Proxy, Firewall など NSG 以外の要因を疑いましょう。

 

バグやフィードバックはコメント欄にどうぞ。


Managed Disks への変換に失敗した件


Managed Disks を検証していたら、エラーで変換できない事象に遭遇したのでメモ。
変換元が SSE (Storage Service Encryption) で暗号化されたストレージだとダメみたい。

<アクティビティ ログ抜粋>
 {
    (中略)
    "properties": {
        "statusCode": "Conflict",
        "statusMessage": "{\"status\":\"Failed\",\"error\":{\"code\":\"ResourceDeploymentFailure\",\"message\":\"リソース操作が完了し、ターミナル プロビジョニング状態は 'Failed' です。\",\"details\":[{\"code\":\"InternalDiskManagementError\",\"message\":\"An internal disk management error occurred.\"}]}}",
        "serviceRequestId": "f98494e5-a880-4eee-92de-1a8122c51f25"
    },
    "relatedEvents": []
}

ドキュメントを読んだらさらに詳しく書いてあって、SSE の暗号化を無効にしても暗号化が解除されるわけではない模様。非暗号化ストレージにコピーして、そこから Managed Disks へ変換って感じですかね。(あと、Managed Disks 上での SSE での暗号化について「今後リリースされる予定です」って書いてありますね。)

Managed Disks と暗号化
SSE では、ストレージ アカウントに書き込まれたデータを暗号化します。 SSE によって暗号化されたことがある VHD ファイルがある場合、その VHD ファイルを使用して Managed Disks を使用する VM を作成することはできません。 また、暗号化された非管理対象ディスクを管理ディスクに変換することもできません。 該当のストレージ アカウントで暗号化を無効にしても、VHD ファイルが元の状態に戻り、暗号化が解除されるわけではありません。

暗号化されたディスクを使用するには、まず、暗号化されたことのないストレージ アカウントに VHD ファイルをコピーする必要があります。 これで、Managed Disks を使用する VM を作成し、作成時にその VHD ファイルを指定できるようになります。また、コピーした VHD ファイルを Managed Disks を使用する実行中の VM にアタッチすることもできます。

SSE 周りももうちょっと勉強しないとダメだなぁ。