Exportera (0) Skriv ut
Visa allt
EN
Det här innehållet finns inte tillgängligt på ditt språk men här finns den engelska versionen,
2 av 4 bedömde detta vara till hjälp - Bedöm det här ämnet

Virtual Network FAQ

Updated: March 19, 2014

Virtual Network Basics

Virtual Network Configuration

Virtual Network Cross-premises Connectivity (VPNs)

Virtual Network and Name Resolution (DNS)

Virtual Network and Virtual Machines

Virtual Network and Services

Virtual Network and Security

APIs, Schemas, and Tools

Windows Azure Virtual Network lets you provision and manage virtual private networks (VPNs) in Windows Azure as well as securely link these with on-premises IT infrastructure. With Virtual Network, IT administrators can extend on-premises networks into the cloud with control over network topology, including configuration of DNS and IP address ranges for Virtual Machines.
For more information, see Virtual Network Overview.

Use Windows Azure Virtual Network to:

  • Securely extend your data center

    With Virtual Network, you can build traditional site-to-site VPNs to securely scale your datacenter capacity. Virtual Network uses industry-standard IPSEC protocol to provide a secure connection between your corporate VPN gateway and Windows Azure. Add as many machines as you want behind the VPN gateway.

  • Enable hybrid cloud scenarios

    Virtual Network gives you the flexibility to support a range of hybrid cloud scenarios. You can securely connect cloud-based applications to any type of on-premises system such as mainframes and Unix systems.

Virtual Network provides the following capabilities:

  • Create a virtual private network in Windows Azure with your own private address space

  • Site-to-site connectivity over IPsec VPN between the virtual network and your on-premises network

  • Use your own DNS servers in the cloud

Virtual Network can be accessed through the Azure Management Portal.

We have Resources that walk you through how to setup a virtual network.

Virtual Network can be used with Cloud Services (PaaS) and virtual machines. Virtual Network cannot be used for any other services at this time.

Yes. Virtual Network can be used without using site-to-site connectivity. This is particularly useful if you want to run domain controllers and SharePoint farms in Windows Azure.

Visit Virtual Network Overview to see a decision table that will help you decide the best network design option for you.

You can use any IP address range defined in RFC1918. This includes IP addresses in the following ranges:

  • 10.0.0.0 - 10.255.255.255 (10/8 prefix)

  • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

IP addresses outside the RFC1918 range are not supported.

There is no limit on the number of subnets you use within a virtual network. All the subnets must be fully contained in the virtual network address space and should not overlap with one another.

We do reserve some IP addresses within each subnet. The first and last IP addresses of the subnets are reserved for protocol conformance. We also additionally reserve a few extra IP addresses for our services.

The smallest subnet we support is a /29 and the largest is a /8 (using CIDR subnet definitions). We reserve some IP addresses from each subnet.

Virtual Networks are Layer-3 overlays. We do not support any Layer – 2 semantics.

No. We do not support custom routing policies with virtual networks.

No. We do not support multicast or broadcast.

We support standard IP-based protocols within the virtual network. We however block multicast, broadcast, IP-in-IP encapsulated packets and Generic Routing Encapsulation (GRE) packets. Standard protocols that work include:

  • TCP

  • UDP

  • ICMP

No. We do not support pinging the default gateway of a subnet.

Subnets can be added to virtual networks at any time as long as the subnet address is not part of another subnet in the virtual network.

You can add, remove, expand or shrink a subnet if there are no VMs or services deployed within it by using PowerShell cmdlets or the NETCFG file. You can also add, remove, expand or shrink any prefixes as long as the subnets that contain VMs or services are not affected by the change.

You can modify the subnet addresses as long as there are no services or VMs deployed within them by using PowerShell cmdlets or the NETCFG file. You cannot modify or delete a subnet once services or VMs have been deployed to it.

Yes. All services deployed within a virtual network can connect to the internet. Every cloud service deployed in Azure has a publicly addressable VIP assigned to it. You will have to define input endpoints for PaaS roles and endpoints for virtual machines to enable these services to accept connections from the internet.

No. We do not support IPv6 with virtual networks.

No. A virtual network is limited to a single region.

No. We do not support this capability today.

Virtual networks supports site-to-site connectivity and point-to-site connectivity. Site-to-site connectivity is over IPsec VPN (IKE v1 and IKE v2). Point-to-site connectivity is over SSTP (Secure Sockets Tunneling Protocol).

Site-to-site connectivity relies on an IPsec VPN appliance (hardware / soft appliance) to be deployed at the edge of your network for connectivity. Based on how routes are configured, this solution offers you the ability to connect between any computers on your premises to any virtual machine / PaaS instance within the virtual network.

Point-to-site connectivity is enabled using the Windows VPN client. You have to install a VPN client configuration package which contains configurations that enable your computer to connect to any virtual machine / PaaS instance within the virtual network.

Currently, you can connect to only one site from a virtual network.

A list of known compatible devices and instructions on how to configure them is available here. Please contact your VPN device manufacturer for additional support.

We have validated a set of standard S2S VPN devices in partnership with device vendors. A list of known compatible VPN devices, their corresponding configuration templates, and device specs can be found here. All devices in the device families listed as known compatible should work with Virtual Network. To help configure your VPN device, refer to the device configuration template that corresponds to appropriate device family.

If you do not see your device listed as a known compatible VPN device and want to use it for your VPN connection, you’ll need to verify that it meets the minimum requirements. Devices meeting the minimum requirements should also work well with Virtual Network. Minimum device requirements are listed below for both static and dynamic route configurations. More information can be found here. Please contact your device manufacturer for additional support and configuration instructions.

We support Windows Server 2012 Routing and Remote Access (RRAS) servers to work as VPN servers. You will have to create a dynamic-routing Virtual Network Gateway in order to use this.

Other software VPN solutions should work with our Gateway as long as they conform to industry standard IPsec implementations. Contact the vendor of the software for configuration and support instructions.

The following operating systems are supported:

  • Windows 7 (64-bit version only)

  • Windows Server 2008 R2

  • Windows 8 (64-bit version only)

  • Windows Server 2012

No. Support is limited only to the Windows operating system versions listed above.

We support up to 128 VPN clients to be able to connect to a virtual network.

At this time, only self-signed root certificates are supported.

Yes. We use SSTP (Secure Sockets Tunneling Protocol) to tunnel through firewalls. This tunnel will appear as a HTTPs connection.

By default, the client computer will not reestablish the VPN connection automatically.

Auto-reconnect and DDNS are currently not supported in point-to-site VPNs.

Yes. Both these solutions will work if you have a dynamic-routing VPN gateway for your virtual network. We do not support point-to-site in static-routing VPN gateways.

Yes, it is possible. But the virtual networks cannot have overlapping IP prefixes and the point-to-site address spaces must not overlap between the virtual networks.

It’s difficult to determine the exact throughput through the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the internet.

It’s difficult to determine the exact throughput through the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the internet.

Static routing VPNs are also referred to as policy-based VPNs. Policy-based VPNs encrypt and route packets through an interface based on a customer-defined policy. The policy is usually defined as an access list.

Dynamic routing VPNs are also referred to as route-based VPNs. Route-based VPNs depend on a tunnel interface specifically created for forwarding packets. Any packet arriving on the tunnel interface will be forwarded through the VPN connection.

No. You have to create your gateway first to get the IP address. The IP address will change if you delete and re-create your VPN gateway.

We generate a pre-shared key (PSK) when we create the VPN gateway. You must use the PSK to authenticate. The PSK can be re-generated at any time and the PSK length can be changed as needed.

We are limited to using pre-shared keys (PSK) for authentication.

We have a gateway service that we run to enable cross-premises connectivity. We need 2 IP addresses from your routing domain for us to enable routing between your premises and the cloud. We require you to specify at least a /29 subnet from which we can pick IP addresses for setting up routes.

Please note that you must not deploy virtual machines or PaaS roles within these subnets.

Add each range that you want sent through the gateway on the Networks page under Local Networks.

No. We do not support configuring routes. You will have to use the virtual network gateway for cross-premises connectivity.

Yes. You can specify DNS server IP addresses in the virtual network definition. This will be applied as the default DNS server(s) for all virtual machines in the virtual network.

You can specify up to 12 DNS servers.

Yes. You can change the DNS server list for your virtual network at any time. If you change your DNS server list, you will need to restart each of the virtual machines in your virtual network in order for them to pick up the new DNS server.

Use the decision table on the Azure Name Resolution page to guide you through all the DNS options available.

Azure-provided DNS is a multi-tenant DNS service offered by us. We register all your virtual machines in this service. This service enables you to have name resolution by hostname for the VMs contained within the same cloud service. You can also use this service to resolve the FQDNs of your VMs within the same virtual network. Note: There is a limitation at this time to the first 100 cloud services in the virtual network for cross-tenant name resolution using Azure-provided DNS. If you are using your own DNS server, this limitation does not apply.

Yes. You can set DNS servers on a per-cloud service basis to override the default network settings. However, we recommend that you use network-wide DNS as much as possible.

No. We do not support the ability to specify a custom DNS suffix for your virtual networks.

We support all Linux distros that are supported in by Windows Azure.

  • An internal IP address (DIP) is an IP address that is assigned to each virtual machine by DHCP. It’s not public facing. If you have created a virtual network, the internal IP address is assigned from the range that you specify. If you do not have a virtual network, an internal IP address will still be assigned. The internal IP address will remain with the virtual machine for its lifetime, unless that virtual machine is Stop (Deallocated).

  • A public VIP is the public IP address that is assigned to your cloud service. It is not assigned directly to your virtual machine NIC. The VIP stays with the cloud service it is assigned to until all the virtual machines in that cloud service are all Stop (Deallocated) or deleted. At that point, it is released.

  • If you deploy a VM to a virtual network, the VM always receives an internal IP address (DIP) from a pool of internal IP addresses that you specify. The DIP is assigned by Windows Azure. It is possible to define a static DIP for your virtual machine if you deploy the VM using PowerShell.

  • Your VM is also associated with a VIP, although a VIP is never assigned to the VM directly. A VIP is a public IP address that can be assigned to your cloud service endpoint. The Windows Azure Load Balancer will then direct the incoming traffic addressed to the endpoint to the correct virtual machine in the cloud service.

Windows Azure will use DHCP to assign an internal IP address to each VM and PaaS instance from the subnet you specify.

Yes. In order to specify the DIP, you’ll need to create your VM using PowerShell cmdlets. There are cmdlets that allow you to specify the DIP that your virtual machine will receive. You’ll need to verify that the DIP that you specify is not being used by another VM or service in your virtual network. When you specify a DIP, it will stay with your virtual machine for its lifetime – even if you Stop (Deallocate) it. If you start the virtual machine again after Stop (Deallocate), it will use the DIP that was previously specified. You don’t need to specify the DIP for a virtual machine unless you require that functionality.

No. You can’t reserve a DIP. If a DIP is available, it’s able to be assigned to a VM by the DHCP server. That VM may or may not be the one that you want the DIP to be assigned to. You can, however, change the DIP of an already created VM to an available address by using PowerShell. At that point, when the desired DIP becomes available in the system, you can then specify it when you create the new VM. You can also release a DIP from a VM by using PowerShell. If you release a DIP, the VM will be assigned a new DIP.

Internal IP addresses remain with the virtual machine for its lifetime unless the VM is Stop (Deallocated). When a VM is Stop (Deallocated), the internal IP address is released unless you defined a static DIP by using PowerShell. If the VM is simply stopped (and not put in the status “Stopped (Deallocated)”) the IP address will remain assigned to the virtual machine.

No. You must not change any interface properties of VMs. Any changes may lead to potentially losing connectivity to the virtual machine.

Nothing. The IP addresses (both public VIP and internal DIP) will stay with your cloud service or virtual machine. Note: if you want to simply shut down the virtual machine, don’t use the Management Portal to do so. Currently, the shutdown button will Stop (Deallocate) the virtual machine.

Stop (Deallocated) is a status that you can specify in the Management Portal by selected to Shut Down the virtual machine. It is different from simply shutting down a virtual machine from inside the virtual machine itself. When you Stop (Deallocate) a virtual machine, you are not only stopping the VM, you are also specifying to release the internal IP address, as well as the public VIP address (if no other VMs are using the public VIP, as the VIP is assigned to the cloud service and not directly to the virtual machine). When you re-allocate the virtual machine, it will then pick up a new public VIP (if it is not joining a cloud service that already has one) as well as a new internal IP address.

The only way to keep the DIP of a virtual machine through a Stop (Deallocated) status is to define a static IP address for that virtual machine. If you find that you have Stop (Deallocated) the virtual machine, but you want the original DIP, you can specify it when you redeploy the VM by using PowerShell if the DIP hasn’t already been assigned to another VM in your virtual network.

Yes. You can use PowerShell to do so. You can find more information here.

No. A MAC address cannot be statically configured.

No. A virtual machine’s MAC address can change for a few different reasons. If the VM is put in the status Stopped (Deallocated), if you change the virtual machine size, or if there is service healing or planned maintenance of the host server, the MAC address is not retained.

Yes. All services deployed within a virtual network can connect to the internet. Additionally, every cloud service deployed in Azure has a publicly addressable VIP assigned to it. You will have to define input endpoints for PaaS roles and endpoints for virtual machines to enable these services to accept connections from the internet.

You can do either. If you have RDP enabled and you have created an endpoint, you can connect to your virtual machine by using the VIP. In that case, you would specify the VIP and the port that you want to connect to. You’ll need to configure the port on your virtual machine for the traffic. Typically, you would go to the Management Portal and save the settings for the RDP connection to your computer. The settings will contain the necessary connection information.

If you have a virtual network with cross-premises connectivity configured, you can connect to your virtual machine by using the internal DIP. You can also connect to your virtual machine by internal DIP from another virtual machine that’s located on the same virtual network. You can’t RDP to your virtual machine by using the DIP if you are connecting from a location outside of your virtual network. For example, if you have a point-to-site virtual network configured and you don’t establish a connection from your computer, you can’t connect to the virtual machine by DIP.

No. Only the traffic that has a destination IP that is contained in the virtual network Local Network IP address ranges that you specified will go through the virtual network gateway. Traffic has a destination IP located within the virtual network will stay within the virtual network. Other traffic is sent through the load balancer to the public networks. If you are troubleshooting, it’s important to make sure that you have all the ranges listed in your Local Network that you want to send through the gateway. Verify that the Local Network address ranges do not overlap with any of the address ranges in the virtual network. Also, you’ll want to verify that the DNS server you are using is resolving the name to the proper IP address.

We support only compute services within virtual networks. Compute services are limited to Cloud Services (web and worker roles) and virtual machines.

No. We do not support websites with virtual networks.

No. We do not support SQL DBs with virtual networks.

Yes. You can deploy PaaS services within virtual networks. You can accomplish this without changing any code.

You can accomplish this by specifying the virtual network name and the role /subnet mappings in the network configuration section of your service configuration. You do not need to update any of your binaries.

No. We do not support the ability to move services in and out of virtual networks. You will have to delete and re-deploy the service into virtual networks.

Windows Azure uses DHCP to assign an internal IP address to each virtual machine and PaaS instance from the virtual network subnet you specify.

Virtual networks are completely isolated from one another and other services hosted in the Azure infrastructure. Trust boundary = virtual network boundary.

No. We do not support ACLs for subnets within virtual networks. However, ACLs can be defined on input endpoints for virtual machines that have been deployed to a virtual network. Note: a virtual machine does not have to be deployed to a virtual network in order to define an ACL for the input endpoint.

Yes. We have REST APIs to manage virtual networks and cross-premises connectivity. More information can be found here.

Yes. We have PowerShell and command line tools for a variety of platforms. More information can be found here.

See Also

Var detta till hjälp?
(1500 tecken kvar)
Tack för dina kommentarer
Visa:
© 2014 Microsoft. Med ensamrätt.