Windows Azure VM - не может установить брандмауэр окон использования ограничения удаленного IP-адреса
В целом для каждого ISP Вы будете (или если) имеют отдельный маршрутизатор. Эти маршрутизаторы каждый предоставят услугу DHCP, где они присваивают IP-адреса компьютерам, подключенным к ним.
Каждый маршрутизатор должен быть настроен, чтобы иметь отдельный пул адресов в, он - пул DHCP. Например, один маршрутизатор мог бы иметь пул от 192.168.1.2 до 192.168.1.254 с маской подсети 255.255.255.0. В этом случае удостоверьтесь, что другой маршрутизатор использует отдельный диапазон и отдельную подсеть такой как 192.168.2.2 до 192.168.2.254 с маской подсети 255.255.255.0.
Если это сделано, компьютер должен взять корректные адреса и не иметь никакого локального конфликта маршрутизации. Я не уверен, какой Windows Server 2003 алгоритма относится к маршрутизации другим сетям, когда маршрутизаторы шлюза имеют те же затраты на маршрутизацию (например, число транзитных участков). Вы, вероятно, найдете, что один ISP одобрен, но если бы, на который снижается ISP, я ожидал бы, что операционная система в конечном счете отметит маршрут и перенаправит трафик к другому ISP. Это - предположение с моей стороны.
Check this forum post for the current behavior of the management portal when creating endpoints: http://social.msdn.microsoft.com/Forums/windowsazure/en-US/8f697f17-72b7-46f7-8c97-398b91190a2f/server-2012-vm-on-azure-passive-ftp-wont-work#aa5d9cdd-41a2-4ac7-87f0-c694f6a9af1a.
Setting IP ACL's on endpoints is currently supported only via PowerShell, not through the portal. If you look at Michael Washam's blog post about this, you can see all the details. In essence, you'll do something like this:
$acl = New-AzureAclConfig
Set-AzureAclConfig -AddRule Permit -RemoteSubnet "w.x.y.z/24" -Order 1 -ACL $acl -Description "..."
Get-AzureVM -ServiceName myservice -Name myvm |
Set-AzureEndpoint -Name myport -Protocol tcp -PublicPort xxx -LocalPort yyy -ACL $acl |
Update-AzureVM
Note: You may get an error when attempting to set the ACL. I've seen this happen with some of my older services, so I suspect that there's been some internal updates to support ACLs that doesn't exist for older deployments. Easily fixed with a remove and re-add of the endpoint needing ACL.