Azure Networking and Connectivity Flashcards
What is an Endpoint?
A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that’s powered by Azure Private Link. By enabling a private endpoint, you’re bringing the service into your virtual network.
What is Azure Virtual Network?
Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. VNet is similar to a traditional network that you’d operate in your own data center, but brings with it additional benefits of Azure’s infrastructure such as scale, availability, and isolation.
Why use an Azure Virtual network?
Azure virtual network enables Azure resources to securely communicate with each other, the internet, and on-premises networks. Key scenarios that you can accomplish with a virtual network include - communication of Azure resources with the internet, communication between Azure resources, communication with on-premises resources, filtering network traffic, routing network traffic, and integration with Azure services.
VNet Peering
Through VNet Peering: You can connect virtual networks to each other, enabling resources in either virtual network to communicate with each other, using virtual network peering. The virtual networks you connect can be in the same, or different, Azure regions.
What does peer to peer mean?
A peer-to-peer (P2P) network is created when two or more PCs are connected and share resources without going through a separate server computer.
Peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions tasks or workloads between peers. Peers are equally privileged, equipotent participants in the network. They are said to form a peer-to-peer network of nodes.[1]
Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts.[2] Peers are both suppliers and consumers of resources, in contrast to the traditional client–server model in which the consumption and supply of resources is divided.[3]
Deploying services within a virtual network provides which capabilities?
- Resources within the virtual network can communicate with each other privately, through private IP addresses. Example, directly transferring data between HDInsight and SQL Server running on a virtual machine, in the virtual network.
- On-premises resources can access resources in a virtual network using private IP addresses over a Site-to-Site VPN (VPN Gateway) or ExpressRoute.
- Virtual networks can be peered to enable resources in the virtual networks to communicate with each other, using private IP addresses.
- Service instances in a virtual network are typically fully managed by the Azure service. This includes monitoring the health of the resources and scaling with load.
- Service instances are deployed into a subnet in a virtual network. Inbound and outbound network access for the subnet must be opened through network security groups, per guidance provided by the service.
- Certain services also impose restrictions on the subnet they are deployed in, limiting the application of policies, routes or combining VMs and service resources within the same subnet. Check with each service on the specific restrictions as they may change over time. Examples of such services are Azure NetApp Files, Dedicated HSM, Azure Container Instances, App Service.
- Optionally, services might require a delegated subnet as an explicit identifier that a subnet can host a particular service. By delegating, services get explicit permissions to create service-specific resources in the delegated subnet.
- See an example of a REST API response on a virtual network with a delegated subnet. A comprehensive list of services that are using the delegated subnet model can be obtained via the Available Delegations API.
What is Network security groups?
You can use an Azure network security group to filter network traffic between Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.
How network security groups filter network traffic
You can use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.
Inbound traffic
For inbound traffic, Azure processes the rules in a network security group associated to a subnet first, if there’s one, and then the rules in a network security group associated to the network interface, if there’s one. This includes intra-subnet traffic as well.
VM1: The security rules in NSG1 are processed, since it’s associated to Subnet1 and VM1 is in Subnet1. Unless you’ve created a rule that allows port 80 inbound, the traffic is denied by the DenyAllInbound default security rule, and never evaluated by NSG2, since NSG2 is associated to the network interface. If NSG1 has a security rule that allows port 80, the traffic is then processed by NSG2. To allow port 80 to the virtual machine, both NSG1 and NSG2 must have a rule that allows port 80 from the internet.
VM2: The rules in NSG1 are processed because VM2 is also in Subnet1. Since VM2 doesn’t have a network security group associated to its network interface, it receives all traffic allowed through NSG1 or is denied all traffic denied by NSG1. Traffic is either allowed or denied to all resources in the same subnet when a network security group is associated to a subnet.
VM3: Since there’s no network security group associated to Subnet2, traffic is allowed into the subnet and processed by NSG2, because NSG2 is associated to the network interface attached to VM3.
VM4: Traffic is allowed to VM4, because a network security group isn’t associated to Subnet3, or the network interface in the virtual machine. All network traffic is allowed through a subnet and network interface if they don’t have a network security group associated to them.
Outbound traffic
For outbound traffic, Azure processes the rules in a network security group associated to a network interface first, if there’s one, and then the rules in a network security group associated to the subnet, if there’s one. This includes intra-subnet traffic as well.
VM1: The security rules in NSG2 are processed. Unless you create a security rule that denies port 80 outbound to the internet, the traffic is allowed by the AllowInternetOutbound default security rule in both NSG1 and NSG2. If NSG2 has a security rule that denies port 80, the traffic is denied, and never evaluated by NSG1. To deny port 80 from the virtual machine, either, or both of the network security groups must have a rule that denies port 80 to the internet.
VM2: All traffic is sent through the network interface to the subnet, since the network interface attached to VM2 doesn’t have a network security group associated to it. The rules in NSG1 are processed.
VM3: If NSG2 has a security rule that denies port 80, the traffic is denied. If not, the traffic is allowed by the AllowInternetOutbound default security rule in NSG2, since a network security group isn’t associated to Subnet2.
VM4: All network traffic is allowed from VM4, because a network security group isn’t associated to the network interface attached to the virtual machine, or to Subnet3.
Intra-Subnet traffic
It’s important to note that security rules in an NSG associated to a subnet can affect connectivity between VMs within it. By default, virtual machines in the same subnet can communicate based on a default NSG rule allowing intra-subnet traffic. If a rule is added to *NSG1 that denies all inbound and outbound traffic, VM1 and VM2 will no longer be able to communicate with each other.
How can we connect from ADF to an On-Premises network? WHat components are required?
- Azure subscription. If you don’t have an Azure subscription, create a free account before you begin.
- Virtual Network. If you don’t have a Virtual Network, create one following Create Virtual Network.
- Virtual network to on-premises network. Create a connection between virtual network and on-premises network either using ExpressRoute or VPN.
- Data Factory with Managed VNet enabled. If you don’t have a Data Factory or Managed VNet is not enabled, create one following Create Data Factory with Managed VNet.
How can we connect from Databricks to an On-Premises network? What components are required?
You can use the JDBC drivers
Create the JDBC URL and Properties
Firstly, you need to create a JDBC URL that will contain information associated with either your Local SQL Server deployment or the SQL Database on Azure or any other Cloud platform. You further need to add other details such as Port Number, User, and Password.
However, unless your database is accessible to the internet it will be unable to connect.
To resolve this you need to vnet attach your databricks workspace to a vnet that has VPN or ExpressRoute connectivity to your onprem site (and correct routing in place). This is currently a preview feature that you will need to contact Microsoft to get enabled.
What does 10.1.1.0/24 mean?
What does 10.1.0.0/16 mean?
Which 2 initual IPs numbers can tou not use in azure?
0, 1, 2, 3 & 255
0 networking
1 2 3 Azure
255 broadcast id
What are the 1 types of security in Vnet config level ?
DDoS protection
Firewall
