Difference between revisions of "Azure/Networking"
Line 34: | Line 34: | ||
= Routing = | = Routing = | ||
== VPN Gateway transit to and from peered networks == | == VPN Gateway transit to and from peered networks == | ||
[[Azure/Point-to-Site VPN]] | |||
== Resources == | == Resources == |
Revision as of 13:13, 31 December 2018
This is being innovated by Microsoft quite often but basis should stay the same. Virtual Network Documentation covers most of the subject here
- routing, service endpoints, security groups, more...
Azure Virtual Network
Resources
Peering
Virtual networks can be in the same, or different, supported Azure regions. The virtual networks can be in the same or different Azure subscriptions.
Naming conventions:
<vnet>_to_<vnet>_peerlink | _prl | _pl | _peer | _pelnk
sandbox_infra1_euw1_to_sandbox_client_euw1_peerlink
Create
Peerlinks need to be created from both ends of Vnet unlike in AWS one connection requests acceptance from other side. In Azure 1st peerlink get status Iniciated then once 2nd peerlink gets created the status changes to Connected.
Options when creating peerlink:
- Allow virtual network access
- Select this option if you wish to allow communication between the two virtual networks. This allows the peer virtual network address space to be included as part of the Virtual_Network tag.
- Allow Forwarded traffic
- This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.It does not create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. You don't need to check this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.
- Allow Gateway transit
- Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings. Check this box if you have a virtual network gateway attached to this virtual network and want to allow traffic from the peered virtual network to flow through the gateway.
VPN gateway
Connects a virtual network to your on-premises network using p2s, s2s or ExpressRoute.
Naming convention:
<project'sVnet>_<region>_vng | _vnetg | vngw
sandbox_euw1_vng
sandbox_infra1_euw1_vng
sandbox_client_euw1_vng
Client Download for p2s connection
The Windows VPN connection name will be a name of VNet where Virtual Gateway resides, eg. sandbox_euw1_vng
Routing
VPN Gateway transit to and from peered networks
Resources
- Virtual network traffic routing
- Configure VPN gateway transit for virtual network peering
- Gateways and on-premises connectivity
Service endpoints
Virtual Network (VNet) service endpoints extend your virtual network private address space and the identity of your VNet to the Azure services, over a direct connection. Allow you to secure your Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on backbone network.
When enabling a service endpoint for an existing subnet, ensure that no critical tasks are running on any resource in the subnet. Service endpoints switch routes on every network interface in the subnet from using the default route with the 0.0.0.0/0 address prefix and next hop type of Internet, to using a new route with the address prefixes of the service, and a next hop type of VirtualNetworkServiceEndpoint. During the switch, any open TCP connections may be terminated. The service endpoint is not enabled until traffic flows to the service for all network interfaces are updated with the new route. To learn more about routing, see Routing overview.
Example service endpoint, these can be fount in Vnet blade > Service Endpoints, and additional added route in Nic > Effective routes
Microsoft.Sql
So the technique that is used with Service endpoints is basically done by creating a route that has “VirtualNetworkServiceEndpoint” as the next hop type.
- Secondary note
A Virtual Network service endpoint is a subnet whose property values include one or more formal Azure service type names. VNet services endpoints use the service type name Microsoft.Sql, which refers to the Azure service named SQL Database. This service tag also applies to the Azure SQL Database, Azure Database for PostgreSQL and MySQL services. It is important to note when applying the Microsoft.Sql service tag to a VNet service endpoint it configures service endpoint traffic for all Azure Database services, including Azure SQL Database, Azure Database for PostgreSQL and Azure Database for MySQL servers on the subnet.
List Service endpoints in Subnet
When creating a subnet following service endpoints are available to enable:
- Microsoft.AzureActiveDirectory
- Microsoft.AzureCosmosDB
- Microsoft.EventHub
- Microsoft.KeyVault
- Microsoft.ServiceBus
- Microsoft.Sql
- Microsoft.Storage
DNS Name Resolution
Resources in one Vnet cannot resolve the names of resources in a peered vnet using built-in DNS. To resolve names in a peered virtual network, requires
- own DNS server
- Azure DNS private domains
Resolving names between Vnet and on-premises networks requires
- own DNS server
Azure DNS Private Zone is in Public Preview.
Services that support Availability Zones
The Azure services that support Availability Zones are:
- Linux Virtual Machines
- Windows Virtual Machines
- Virtual Machine Scale Sets
- Managed Disks
- Load Balancer
- Public IP address
- Zone-redundant storage
- SQL Database
- Event Hubs
- Service Bus
- VPN Gateway
- ExpressRoute
- Application Gateway (preview)
Resources
- Virtual Network Service Endpoints
- Virtual Network Azure updates