Agregué mi función a una subred virtual y configuré grupos de seguridad de red para permitir la entrada de 63389 a 3389. Probé varias permutaciones de 3389 a 3389, pero nunca puedo hacer que RDP funcione. Si elimino el NSG, funciona bien. Básicamente estoy haciendo lo que dice.aquí
Esto es lo que estoy usando actualmente para mi subred web_sg 10.1.0.0/16
# RDP inbound
Get-AzureNetworkSecurityGroup -Name "web_sg" | Set-AzureNetworkSecurityRule -Name RDP-web_dmz -Type Inbound -Priority 347 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '63389' -DestinationAddressPrefix '10.1.0.0/16' -DestinationPortRange '3389' -Protocol TCP
# SSL Inbound
Get-AzureNetworkSecurityGroup -Name "web_sg" | Set-AzureNetworkSecurityRule -Name SSL-web_dmz -Type Inbound -Priority 348 -Action Allow -SourceAddressPrefix '*' -SourcePortRange '*' -DestinationAddressPrefix '10.1.0.0/16' -DestinationPortRange '443' -Protocol TCP
También probé 3389 -> 3389 y * -> 3389 y también los agregué como puntos finales en mi servicio en la nube. Tenga en cuenta que estoy habilitando el escritorio remoto manualmente mediante el sitio web de administración de Azure.
¿Algunas ideas?
Respuesta1
Si su servicio en la nube se encuentra detrás de un NSG, es posible que deba crear reglas que permitan el tráfico en los puertos 3389 y 20000. El Escritorio remoto usa el puerto 3389. Las instancias del servicio en la nube tienen equilibrio de carga, por lo que no puede controlar directamente a qué instancia conectarse. . Los agentes RemoteForwarder y RemoteAccess administran el tráfico RDP y permiten al cliente enviar una cookie RDP y especificar una instancia individual a la que conectarse. Los agentes RemoteForwarder y RemoteAccess requieren que se abra el puerto 20000*, que puede estar bloqueado si tiene un NSG.