使用 Azure IaaS（通过 ARM），我有一个配置，其中包含一些非域认证的 RDP 网关。这些设备用作虚拟网络的垫脚石，然后允许继续连接到虚拟网络上所有域注册的设备。
我没有任何声誉，所以无法插入内联图像。查找图表这里
一般来说，这可以按预期工作，允许 RDP 访问域中的所有设备（显示为子网 10.1.10.0/24 和 10.1.11.0/24），但域控制器除外，因为无法以这种方式可靠地登录。
最常见的症状是连接失败，但有时 RDP 会话可以正确启动，然后失败（几秒钟后）。
如果我设置从（例如）10.1.10.0/24 子网中的设备到域控制器的永久 ping，这些 ping 会一直响应，直到 RDP 连接失败，此时它们会被丢弃。RDP 失败消息返回或 RDP 连接终止后，ping 会再次响应。
如果我设置从域控制器到（例如） 10.1.10.0/24 子网中的设备的永久 ping，则这些 ping 总会得到响应，即使另一个方向的 ping 失败也是如此。
如果我使用可公开路由的 IP 地址来显示域控制器，并允许该入站流量通过域控制器网络安全组，我就可以从公共 IP 地址可靠地进行连接（使用与上面相同的凭据），但这正是我试图通过此配置避免的。
如果我设置对公共可路由 IP 地址的永久 ping，即使在内部 ping（上面的第一个要点）失败的情况下，它也总是会成功。
如果我在域控制器子网中创建另一个默认安装（未加入域）虚拟服务器，则不会出现同样的问题。如果我将新服务器加入域，它仍然不会出现问题。显然，这与 DC 有关。
所有 Azure 设备的 DNS 记录都指向域控制器，其他一切表面上都正常，尽管域控制器没有启用任何其他服务。
所有服务器都是Windows2016。
我错过了什么？当域控制器在 vNet 内部有持久连接，但在外部没有持久连接时，是什么原因导致域控制器丢失入站连接？
答案1
看来，这个问题的答案在于我无法遵循指示。
微软状态域控制器虚拟机应通过 Azure NIC 配置配置其静态 IP 地址。不太清楚的是，您根本不要在来宾操作系统中配置任何静态地址的重要性。 Petri.com 的措辞更为有力：
“您永远不应该在客户操作系统中配置 Azure 虚拟机的 IP 配置。新的域控制器会抱怨有 DHCP 配置 - 让它抱怨，因为如果您遵循正确的程序，就不会有任何危害。”
如果您不遵循此建议，则可能会出现上述症状。