Implement Azure Infrastructure

18. IP Addressing Overview

Now that we've deployed a few different services, especially some infrastructure services and even the path services in the form of the storage accounts, we can start looking at some more advanced networking features. The first thing we're going to look at is IP addressing, so we can assign IP addresses to Azure resources to communicate with other Azure resources, your onpremise network, or even the Internet. And to support this, there are two types of IP addresses you can use. Virtual networks can contain both public and private IP addresses. IP addresses are often used for communication between the Azure virtual network and your own on-premises network via a VPN gateway or express route. Public IP addresses are used for communication with the Internet, including Azure public-facing services. IP addresses can also be either statically assigned or dynamically assigned. Static IP addresses are the best option for certain situations, such as DNS name resolution where the IP address would require updating horse records, IP address-based security models that require apps or services to have static IPSSSL certificates that are linked to an IP address, and when you need firewall rules that allow ordinary traffic on specific IP addresses. Finally, role-based VMs such as domaincontrollers and DNS servers are often best suited to static DNS addresses. As a best practice, you may decide to separate dynamically and statically assigned IP resources into different subnets. And IP addresses are never managed from within a virtual machine, but through the Azure platform itself. A public IP address can be associated with virtual machine network interfaces, internet-facing loadbalancers, VPN gateways, and application gateways. Azure can provide an IP address using dynamic assignment, or you can sign the IP address using static assignment. The types of resources affect the assignment. So, as we can see from this chart,virtual machines, load balances, VPN gateways, and appgateways can all have dynamic addresses. But only virtual machines and load balancers can be configured with static addresses. When you create a public IP address, you are given an SKU choice of either basic or standard. The SKU choice affects the IP assignment,method, security, available resources, and redundancy. And this table summarises the main differences. Basic SKUs can have static or dynamic IPS, are open by default in terms of security, and can be assigned to network interfaces, VPN gateways, application gateways, and internet facing load balancers. However, they are not zoned redundant. So if you lose one zone, you lose access to that IP address using the standard SKU that costs a little bit more and has slightly different features. For example, you can only assign IPS from a security perspective. They are secured by default and close to inbound traffic. However, you can only assign them to network interfaces or public standard load balancers,but they are zone redundant. This means an IP address in one particular zone. If you were to lose that zone, the IP would still be available in the other zone. A private IP address resource can be stored. initiated with Virtual Machine Network interfaces,internal load balancers, and application gateways. Azure can provide an IP address dynamically again and again. You can assign it statically. A private IP is best allocated from the address range. The virtual network subnet in which a resource is deployed. If we deploy the IP address as dynamic, Azure assigns the next available unassigned or unreserved IP address in the subnex range. So, for example, Azure assigns ten zero-ten to a new resource. If addresses 100, 410, or nine are all really assigned to other resources, dynamic addressing is the default allocation method. With Static, we can select and assign any unassigned or unreserved IP address in the subnet range again. So if we've got a subnet range in the 1016space and addresses four to nine are already assigned, With the resources, we can manually sign any other address from ten up to 250. Again, private IP addresses have their own options. So, for example, dynamic addresses can be assigned to virtual machine mixinternal load balances in the gateway. However, app gateways can't have static addresses, only virtual machines and internal load balancers. Let's now have a look at an example of how we can manage IP addresses on one of our virtual machines.

19. IP Addressing Walkthrough

So let's have a look at the Windows virtual machine that we created earlier. On the main overview of this page, we can see first of all that we have a private IP address and then we have a public IP address. If we click on the public IP address first, it takes us to the configuration of the public IP. From here, we can see that the assignment of this public IP address is dynamic. This means that although we could connect to it over the Internet at that address, it will change from day to day. There are two ways we can get around this. If we don't want this to happen, or at least if we want to be able to access the virtual machine from a common place, The first is that we could give it a DNS name. So, for example, at the moment there will be some names on Uksylecloud Azure.com. So we could put the Guru 19 server. If we tap out that box, it will then go ahead and check to see if that domain name is available. If we go ahead and save this, it means we can then access this VM over the internet using that fully qualified domain name. And it doesn't matter what the underlying IP address changes to, it will automatically update that DNS for us. Alternatively, we could simply set it to static. This will mean that it will be assigned a public IP address and then that IP address will never change. There are costs associated with that. They're not much, and they vary from region to region. But if you need a publicly available IP that is isostatic, this is the way we would do that. And again, we can continue to use our DNS labels with it as well for easier memory access it.If we go back to the details of our virtual machine, we can see our private IP address there. Again, however, there is no linkthrough to actually access it. What we can do, however, is down the left hand side of the pane, go to Settings and Networking, and we can see here that it tells us which network security group we are using, which we'll come to later. However, we can see that it's attached to a network interface, and that's our actual network interface, which in turn gets the private IP. We can click that to get through to it, but we won't do that for now. First of all, I would like to go to the top menu and look at all your resource groups. And now go to the resource group that continues your Windows servers. And this again shows the two items that we're interested in. So there's the public IP that we were looking at earlier, and again, here is the network interface. So let's just show you the two different ways you can get to the network interface and IP address. We're going to go and have a look at the network interface now and again. The overview page just shows us some basic overview information. We'll go to IP configurations in a minute. First of all, let's just have a look at DNS servers. So by default, we can sign specific DNS servers. So if this virtual machine was on a network that's connected to our internal network, we could use our internal DNS servers and add them here. As you can see, by default, what it does is inherit from the virtual network. We can also go to Network Security Group and this is where we can define the actual network security group that defines our roles that we have, such as all the ports that we have allowed in when we built the virtual machine, we set to allow RDP again. If we click on that, it will take us through to the network skuter group. We'll be covering network skewer groups in more detail later on. So for now, let's just go to IP configurations. So here is where we can see the IP configuration and, in particular, the fact that our private IP is currently set to dynamic. If we click on that, we then get the option to look above the public IP. Again, if we click on there, we can see the actual public IP object that's created. We can see the virtual network and subnetwork that this interface is actually connected to. And more importantly, we can see that the assignment is set dynamically. So if you want to change that to static, simply click on static and click save. And once that's saved, that means that IP address is now static. Go back level to the IP configurations and confirm that there we can see the private IP address and it is now set to static. Now let's have a look at the information and set this using PowerShell because this is often quite a handy thing to be able to do and you do need to have an overview of how to perform some of these tasks. For the exam Go up and open your cloud PowerShell, and the first thing we're going to do is issue an command in PowerShell to actually get the network interface. What we're also going to do is assign that information to an actual object, which we'll call Dollar Nick, and that will help us perform the next step when we want to change the IP details. So we'd like to say, "Get the hyperac network interface." We need to type the name of the interface, which is Cloudguru Nineteen Zero, and we need to tell it the resource group name, which is Rsgwin servers. If we now type Dollar Nick again, it will then provide us with all the details that we have for the network interface. So as you can see, we've got the name,the resource group, the location and so on. A bit of interest at the moment is this IP configuration. This denotes that it's actually an array and here we can see for each of the IP configurations that we've got the name and the details. Again, note that the privateIP allocation method is set to static, so let's go ahead and change that back to dynamic now in PowerShell. The first thing we can do is we'll just confirm which IP configuration it is, so we'll do dollarnick, then we'll do dot and we'll say IPconfigurations, which is basically referencing this property. The IP configurations property and because it's an array, we want to tell it which item in there. Arrays always have a zero-based index, so we will do zero and then we can say dot private IP allocation method, which was that value thereand then hit enter and we can see it is currently set to static. We need to do that as an astring, so we put it in quotes so that is updated. So what we now need to do is update the actual IP address with the network interface with the details of that object that we've created. To do that, we type setAZ network interface network interface, so we're now passing it the interface details that we want to update and we say dollarnick. That will take a few seconds. Once that's done, we can see that it's automatically updated itself there to dynamic, and again, if we just drill back down again, we can see that it's set to Dynamic. So for the exam, it's important to understand the differences between public and IP allocations and how we set them both through the GUI and the different use cases for each one.

20. Network Security Groups

An important part of securing your Azure infrastructure is through the use of networksecurity groups, often shortened to NSGs. We can limit network traffic to resources within a virtual network using a network security group. A network skuter group contains a list of security rules that allow ordinary inbound and outbound traffic. An SG can then be associated with a subnet or network interface. In many ways, network security groups work just like traditional firewalls. So in a traditional three-tier application, you might have a network security group in front of the publicly available web tier, which would allow users to only exit on, say, HTTP or HTTPS. You then might have another network security group between the web tier and the business tier that handles business logic. And again, this network security group may again limit onports four, four, three, and 80 i, as well as Http and Https. But it might also be locked down so that it only allows traffic from the web tiernetwork, thus preventing direct access from the Internet. And finally, you might have a third tier,a data tier, where your databases reside. And again, this might also be wrapped with a network security group, this time that allows access only from a specific network, such as the business tier, but maybe on a different port, such as port 1433. So it's important to understand how network security groups work, how we configure them, and how we can use them to secure our infrastructure. In general, Msgs can be applied to subnets and network interfaces. You can assign NSGs to subnets to create protected screen subnets, sometimes called the DMZ, and these can restrict traffic flow to all the machines within that subnet. Each subnet can have zero, one, or more associated network scooter groups. Alternatively, you can apply scootergroups directly to network interfaces. That way, the Nic itself has its own NSG rules. And in fact, we can use these rules in conjunction with network security rules applied to subnets. Security rules in a network security group enable you to filter the type of network traffic that can flow in and out of the virtual network subnet or network interface. Azure creates several default security rules within each network, which we'll cover shortly. However, you can add your own rules by specifying the priority, i.e., in what order the rules are applied in the protocol, such as TTP or UDP, a short name that's just a description for yourself. So, for example, you might use the format allow Httpbound the source, which can be either an individual IP address, an IP range, a specific subnet within Azure orVNet within Azure, or a service tag, or simply setto any which will allow any traffic. Similarly, you also define the source port. You would set 22 to allow SSH trafficking, 3389 for RDP, eight for HTTP and so on. We also set the destination address and ports. And again, these are the same with ports, but this time we are setting the destination to allow whether you want the traffic to go And finally, boot rules can be either allowed or denied. So a common use case for this might be to set deny all on a low priority, but then allow individual ports through as an allow setting at a higher priority. When you create a network security group, Azure automatically creates three default inbound and outbound security rules. These rules deny all inbound traffic except from the virtual network and Azure's internal load balancers. So it's important to understand that these get set by default. You can change these, but it is not advisable generally. You would then build your own rules on top of these to allow access to the services you want to allow access to. Because you can provide NSG's at the subnetlevel and the network interface level, you have to be careful when you're applying them. Network security groups are evaluated independently and an allow rule must exist at both levels, otherwise traffic will not be admitted. So if there was incoming traffic on port eight, you would need to have the NSGat the subnet to allow port eight. And you would also need another NSG with the same rule on port 80 at the Nic level. For incoming traffic, the NSG set at the subnet level is evaluated first, and then the NSG at the interface level is evaluated. The outgoing traffic is the opposite.

21. Network Security Groups Walkthrough

Let's have a walkthrough on configuring a network security group. Now we've actually done quite a lot of this when we've been building our virtual machines because we were setting network security rules to allow SSH for Linux servers and RDP for Windows servers. We're looking at the Linux server at the moment that we built in an earlier lecture, and we can see that we've got a public IP address and we also have a virtual network and subnet assigned. If we go down to the left to networking, we can see the inbound rules that we have. We have the three default rules that get created by Azure whenever we create a virtual network. We can also see the SSH rule that we created when creating the subnet ourselves. We're going to examine using Network Security group rules by installing an Internet site on our Linux server and then trying to access it. So the first thing we're going to do is install Apache on our server. So I'm going to SSH to the server and then I'm going to install Apache once that's completed. It's now running an Apache web server on our Linux box that's displaying a simple site by listening on port eight. The first thing I'm going to try is to browse to that website on its IP address and eventually it will timeout and fail. And that's because we're currently allowing HTTP through. So now we'll add an inbound rule. We'll set the source to any, the destination we will set to any, and we will set the port to 80. We'll set the priority at one 10. Change the name to allow Http and then, once that's done, go to our browser window and try to browse again. We'll get the Apache default page. So, by simply adding that simple network rulethrough, we have allowed access to the website. It is important to understand that we have inbound and outbound rules. So even though we can now http into the server, if we were going to the server and typing http out, it still wouldn't work because we hadn't allowed the rule.

22. Peering Overview

When we want to connect different VNETs together, perhaps the simplest and quickest way is to connect them using VNet Peering. Azure Virtual Network peering enables you to seamlessly connect to Azure virtual networks. At least for connectivity purposes, the virtual networks appear as one. There are initially two types of VNet peering. There's regional VNet peering, which is what happens when you connect to virtual networks within the same region. For example, two VNETs within the UK are part of this global VNet pairing, which connectsvirtual networks between different regions. For example, if you wanted to go from the UK south to the UK west, there are various benefits to using low global virtual network peering, which includes private sector network traffic. All network traffic between periodvirtual networks is completely private. Traffic between the virtual networks is kept on the Microsoft Backbone network. No public Internet gateways or encryption is required. In the communication between theBnits, there's great performance. A low latency, high bandwidth connection between resources in different virtual networks exists. The ability for resources in one virtual network to communicate with resources in another virtual network once the virtual network disappears makes connectivity much simpler. It's seamless with the ability to transfer data across Azure subscription deployment models and across Azure regions. And then there's no disruption. There is no resource downtime in either Virtual Network. When creating peering connections, the default pairing configuration provides full connectivity. So you can see how NSG should also be applied to block or deny access as required. When using global Venus peering, it's important to understand that there are some constraints. First of all, it has to be in public clouds, not national clouds. So national clouds are physically and logically-isolated instances of Microsoft Enterprise cloud services,for example, used for government customers. The IP address of an Azure internalload balancer in the peer virtual network cannot be communicated with by resources in one virtual network. In other words, the load balancer and the resources that communicate with each other must allexist within the same Virtual Network Gateway Transit. You should not configure your use of remote gatewaysor loud gateway transit. Gateway transit only applies to regionally renewed virtual machines; high-performance compute ID H series and GPUcomputers I N series are not available. Finally, another important aspect of VNet Peering orGlobal Venet Peering is that Venet global pairingsare not transitive, meaning downstream Venus in one region can't talk to another. So, for example, if we peered VNet One to VenetTwo and then we peered Venet Two to VNet Three,there is no implicit pairing between VNet One and three. In order for VNet One to be able to communicate with VNat Three, you would have to set up a separate peering. When you allow gateway transits, the virtual network can communicate resources outside the peering. For example, using gateway transit with a subnet gateway could set up a site-to-site VPN to connect to an on-premise network, use a VNet to VNetconnection to connect to another virtual network, or use a point-to-site VPN to connect to a client. In these scenarios, Gateway Transit allows peer virtual networks to share the gateway and get access to resources. This means you don't need to deploy your VPN gateway on the Peer Virtual Network. When you create your virtual network gateway, gatewayVMs are deployed to the gateway subnet and configured with the required VPN gateway settings. You must never actually deploy anything else. For example, adding additional VMs to the gateway subnet. The gateway subnet must also be called gateway. gateway subnet. Now, let's move forward to an example of how we set up simple peering.

ExamSnap's Microsoft AZ-303 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Microsoft AZ-303 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.