主页 / server / 问题

问题[azure](server)

Martin Hope
Shadi
Asked: 2025-02-12 03:25:08 +0800 CST
  • 5

我正在测试一种场景，我们需要将所有流量转发到一台虚拟机，然后这台虚拟机应该将流量转发到目标机器。（不能说“为什么”）。

  1. 创建了Vnet "VN"、、Subnet "SN"3NICs和 3 VMs（使用：Standard_DS1_v2大小和最新的Win 2022 image）。
  2. 所有内容均位于同一帐户和订阅下的同一个 Azure 区域内。
  3. 创建routing table "RT"并添加了两个routes。
  4. 使VM2的 IP 变为静态。
  5. IP Forwarding已启用VM2。
  6. 在所有虚拟机上禁用 Windows 防火墙。

IP 包括：

VM     |     IP
----------------------  
VM1    |     10.3.1.4  
VM2    |     10.3.1.5  
VM3    |     10.3.1.6

RT 路线：

Name     |   Address Prefix |     Next Hop Type       |    Next Hop Address
----------------------------------------------------------------------------
VM1-VM3  |   10.3.1.6/32    |     Virtual Appliance   |    10.3.1.5
VM3-VM1  |   10.3.1.4/32    |     Virtual Appliance   |    10.3.1.5

在将路由表附加RT到SN子网之前，网络正常，我可以ping从任何地方到任何地方。

附加到 后RT，SN从任意位置 ping 任意消息“ Request timed out”。

我尝试过的：

  1. 不同的子网：也不起作用。
  2. 添加nsg和允许ICMP。
  3. 添加nsg并允许所有流量（any至any）。
  4. 重现整个事情。
  5. 不同的帐户和订阅。
  6. 问AI是否可能。它回答“是的”。
  7. 尝试了许多 YouTube 视频，结果相同。唯一的区别是他们使用真实的（付费）Azure 帐户。
  8. 我甚至尝试安装路由和远程访问服务 (RRAS)，将其配置为 LAN 路由，并添加以主机网关为网关的静态路由。

我别无选择，也毫无头绪。

怎么了？

azure
Martin Hope
Peter Kahn
Asked: 2024-12-05 03:28:56 +0800 CST
  • 6

我看到azurerm提供程序有azurerm_monitor_metric_alert但似乎不支持azure 配额警报。各种 AI 认为我可以使用azurerm_monitor_metric_alert类似“/subscriptions/${data.azurerm_subscription.current.subscription_id}/providers/Microsoft.Compute/locations/${location}/providers/Microsoft.Quota/quotas/standardDPLDSv5Family”的范围

但事实似乎并非如此。似乎无法通过 Terraform 管理订阅配额警报。是这样吗？

azure
Martin Hope
Michael Brown
Asked: 2024-10-10 21:24:55 +0800 CST
  • 5

我在使用 AzCopy 时遇到了一个问题，我的脚本在 CMD 中运行正常，但通过批处理文件执行时却出现身份验证错误。以下是情况的细分：

目的是通过任务计划程序将我们的日常文件备份到存储帐户中；很可能每天/运行仅 1 个文件。

我的批处理脚本：

@echo off
cd "C:\Program Files\AzCopy"
azcopy cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false

当我在 CMD 中手动运行此命令时：（导航到 AzCopy 目录之后）

azcopy cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false

它运行完美，并且所有文件都按预期上传。

但是，当我运行批处理文件时，我得到：

RESPONSE Status: 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

我还尝试修改批处理文件，以便它打开 CMD 并运行命令，就像我手动执行一样：

start cmd /k ""C:\Program Files\AzCopy\azcopy.exe" cp "G:\Backup\UATBackups\*" "https://<storage-account-name>.blob.core.windows.net/test/?sp=rw&st=2024-10-08T15:28:58Z&se=2024-10-08T23:28:58Z&spr=https&sv=2022-11-02&sr=c&sig=<SAS-token>" --recursive=true --block-blob-tier=Cold --overwrite=false"

但这给了我：

RESPONSE 401: 401 Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
ERROR CODE: NoAuthenticationInformation

我已经检查过的事项：

  • SAS 令牌有效且未过期。
  • VM 时间已正确同步。
  • 我使用同一个用户帐户来运行 CMD 和批处理文件。

我的问题：

  • 为什么当我在 CMD 中手动运行该命令时，它能完美运行，但通过批处理文件运行时（即使使用相同的用户帐户）却出现 403 错误？
  • 需要改变什么以及我如何解决这个问题！

任何帮助或建议都将不胜感激。谢谢！

azure
Martin Hope
Swiftniscate
Asked: 2024-08-31 05:23:49 +0800 CST
  • 4

我在 Azure 中安装了一台 centos 机器，它的 ip 地址是 10.5.0.4，然后我在 Azure 中安装了一台 openVPN 机器，它的私有地址是 10.6.0.4。我在 centOS 和 openVPN 网络之间进行了对等连接，并且运行良好，所以我可以互相 ping 通。

当我用电脑连接到 openVPN 时，我的本地电脑被赋予了私有 IP 地址 10.6.0.2。我可以从 10.6.0.2 ping 到 10.6.0.4，这没问题，但我无法从 10.6.0.2 ping 到 10.5.0.4。我认为 openVPN 不会将 10.6.0.2 流量路由到 10.5.0.4。我该如何进行这种路由？

azure
Martin Hope
The Fabio
Asked: 2024-08-08 08:50:11 +0800 CST
  • 6

在 Azure devops 脚本中将 signtool.exe 与“Azure 受信任签名帐户”结合使用时，该过程挂起在：

正在提交摘要以供签名...

这是我们在 Azure devops 使用的 PowerShell 脚本块，它基于Azure 受信任签名帐户的文档：

    - task: PowerShell@2
      displayName: Preparing Windows EXE signing tools
      inputs:
        targetType: 'inline'
        workingDirectory: $(Pipeline.Workspace)/windows-signing-tool
        script: |
          Set-PSDebug -Trace 1
          Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile .\nuget.exe
          .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
          .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
          ./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

日志输出：

========================== Starting Command Output ===========================
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\c16ea5da-1997-4e32-9ef5-9e9268766943.ps1'"
DEBUG:    5+  >>>> Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile 
.\nuget.exe
DEBUG:    6+  >>>> .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
Feeds used:
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 751 ms
Attempting to resolve dependencies for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Resolved actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Retrieving package 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg 7ms
Installed Microsoft.Windows.SDK.BuildTools 10.0.22621.3233 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.windows.sdk.buildtools\10.0.22621.3233 with content hash v67zwCb9JOpfPxdSroZukIKHruU6FUB+KwcmSPcVvUFyYtcyvcUign5y8jPQNi54CVzWvaTg646e62LbanUkxg==.
Adding package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 5.09 sec
DEBUG:    7+  >>>> .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
Feeds used:
  C:\Users\VssAdministrator\.nuget\packages\
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Trusted.Signing.Client.1.0.53' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 1.09 sec
Attempting to resolve dependencies for package 'Microsoft.Trusted.Signing.Client.1.0.53' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Resolved actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Retrieving package 'Microsoft.Trusted.Signing.Client 1.0.53' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg 9ms
Installed Microsoft.Trusted.Signing.Client 1.0.53 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.trusted.signing.client\1.0.53 with content hash lou6NowgbY3S/Yn0+WSeI+Dl8SCmvmqkeAzt2Pgs51QL5/kHh+w8FJgutYGM+j2TB11a9zNc0EBWjOGWdwWtoQ==.
Adding package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Trusted.Signing.Client 1.0.53' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 1.45 sec

这意味着前三个命令运行正常......

之后我们有：

./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

Trusted Signing

Version: 1.0.53

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

在本地执行时，同样的最后一条命令的输出是：

Trusted Signing

Version: 1.0.60

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

OperationId 12121212-acbc-acbc-acbc-49603042d34c: InProgress

Signing completed with status 'Succeeded' in 20.5563194s

Successfully signed: <obscurecFolder>/MyProject.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

为什么 signtool.exe 在由 devops 运行时无法继续，但在我的本地环境中却可以正常运行？

azure
Martin Hope
JohnLBevan
Asked: 2024-08-02 00:32:34 +0800 CST
  • 5

我有一个应用程序网关，我的后端设置配置了健康探测，允许状态 200-499 为健康（我之所以包含4xx系列代码，是因为某些解决方案的站点根目录返回 404，而其他路径下有内容，而某些站点会自动为未经授权的用户返回 403 / 我不希望这些影响后端健康状态 / 我希望我的解决方案尽可能通用，这样我就可以重复使用一系列站点上的相同设置，以尽量减少新站点加入时的工作量）。

但是，我的后端健康状况显示我的一个站点正在返回HTTP 463状态代码（因此后端仍然健康，但此响应是意外的）。此外，如果我导航到与此后端关联的侦听器的 URI，我会陷入 301 重定向到/来自同一站点。我确实配置了重定向：

  • 对于未经身份验证的用户，后端会从 重定向/到/login.aspx。这使用相对路径，因此不受 AppGW 的主机名或前端与后端协议的影响。
  • AppGW 有 HTTP 和 HTTPS 监听器，HTTP 规则重定向到 HTTPS 监听器，而 HTTPS 规则与后端相关联。

然而，即使我删除这些功能，仍然会得到相同的行为。

同一 AppGW 上的其他站点以相同的方式设置，但没有这个问题。

我有一个用于测试重定向的 PowerShell 脚本：Get-HttpUrlRedirects。如果我们假设配置为example.com，则运行的预期输出Get-HttpUrlRedirects -Url 'http://example.com' -Verbose将是：

VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/login.aspx]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   302
https://example/login.aspx                             200

而实际输出是：


VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]

# etc - I hit ctrl + C to terminate when I see this loop occurring
azure