Difference between revisions of "Azure/Networking"
(One intermediate revision by the same user not shown) | |||
Line 103: | Line 103: | ||
</source> | </source> | ||
Verify | |||
<source lang=bash> | <source lang=bash> | ||
# Created VM named switch-1 | # Created VM named switch-1 | ||
piotr@switch-1:~$ cat /etc/resolv.conf | |||
nameserver 127.0.0.53 | |||
search aaaa4akypjlederrplo5zraaaa.bx.internal.cloudapp.net | |||
piotr@switch-1:~$ cat /etc/hosts | piotr@switch-1:~$ cat /etc/hosts | ||
127.0.0.1 localhost | 127.0.0.1 localhost | ||
Line 111: | Line 118: | ||
::1 ip6-localhost ip6-loopback | ::1 ip6-localhost ip6-loopback | ||
fe00::0 ip6-localnet | fe00::0 ip6-localnet | ||
<omitted> | |||
ff02::3 ip6-allhosts | ff02::3 ip6-allhosts | ||
piotr@switch-1:~$ nslookup switch-1 | piotr@switch-1:~$ nslookup switch-1 | ||
<omitted> | |||
Non-authoritative answer: | Non-authoritative answer: | ||
Name: switch-1.aaaa4akypjlederrplo5zraaaa.bx.internal.cloudapp.net | Name: switch-1.aaaa4akypjlederrplo5zraaaa.bx.internal.cloudapp.net |
Latest revision as of 11:23, 17 January 2019
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
Private DNS zones
A DNS zone is used to host the DNS records for a particular domain. To start hosting your domain in Azure DNS, you need to create a DNS zone for that domain name. Each DNS record for your domain is then created inside this DNS zone. To publish a private DNS zone to your virtual network, you specify the list of virtual networks that are allowed to resolve records within the zone. These are called resolution virtual networks
. You may also specify a virtual network for which Azure DNS maintains hostname records whenever a VM is created, changes IP, or is deleted. This is called a registration virtual network
.
Create DNS private zone
# Private zone can be only created in empty Vnet az network vnet create \ --name myAzureVNet \ --resource-group MyAzureResourceGroup \ --location eastus \ --address-prefix 10.2.0.0/16 \ --subnet-name backendSubnet \ --subnet-prefix 10.2.0.0/24 az network dns zone create -g MyAzureResourceGroup \ -n us.sandbox.local \ --zone-type Private \ --registration-vnets myAzureVNet az network dns zone list --resource-group MyAzureResourceGroup az network dns record-set a add-record \ -g MyAzureResourceGroup \ -z us.sandbox.local \ -n db \ -a 10.2.0.4 az network dns record-set list \ -g MyAzureResourceGroup \ -z us.contoso.local
Verify
# Created VM named switch-1 piotr@switch-1:~$ cat /etc/resolv.conf nameserver 127.0.0.53 search aaaa4akypjlederrplo5zraaaa.bx.internal.cloudapp.net piotr@switch-1:~$ cat /etc/hosts 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet <omitted> ff02::3 ip6-allhosts piotr@switch-1:~$ nslookup switch-1 <omitted> Non-authoritative answer: Name: switch-1.aaaa4akypjlederrplo5zraaaa.bx.internal.cloudapp.net Address: 10.155.96.4 # this is registered DNS record piotr@switch-1:~$ nslookup switch-1.us.sandbox.local Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: switch-1.us.sandbox.local Address: 10.155.96.4
If you wanted to create a zone just for name resolution (no automatic hostname creation), you could use the resolution-vnets
parameter instead of the registration-vnets
parameter.
Azure DNS Private Zone is in Public Preview since 22 March 2018
Docs:
Availability Zones
Azure Virtual Networks (VNETs) and Subnets, are and will remain "regional" entities. Once you will define in a region, they will be visible and usable across all the AZ since Network Resource Manager in Azure is region-wide. There is no AZ specification for these objects, VNETs and Subnets can cross AZ.
Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.
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
- Azure Availability Zones 5+
- Virtual Network Service Endpoints
- Virtual Network Azure updates