Microsoft Azure Master Class Part 6 - Networking

hey everyone welcome to the networking module of the azure master class and my goal for this module is to really explore the core fundamental virtual network functionalities the connectivity i can establish with that virtual network connecting things to it and then controlling the flow of traffic things like the azure load balancers networking for kubernetes um virtual when i have other videos on those i'm not going to cover those topics here so let's kind of get into it so when i think about a virtual network this is the building block of all of the networking in azure a virtual network basically consists of one or more ip ranges now typically those ip ranges will be from the rfc 1918 the 10 dot or 172 16 the 192 168 they don't have to be if you were one of those kind of people around the dawn of networking and maybe you have your own kind of class b in some way you could absolutely bring a portion of that network space to azure it doesn't mean it would work on the public internet the only public ips i can use from azure are ones that azure provides i cannot bring my own public ip but i could still use that ip space on the azure network if i wanted to if i was going to connect things in azure to on-prem and already had an ip space i wanted to use i don't have to use the rfc 19 but for most of us we're going to want to use rfc 1918 now when i think about what is a virtual network it's a boundary of communication until i start connecting it to other things other networks for example but that virtual network itself well it lives within a specific subscription and it lives within a specific region so i cannot span subscriptions i cannot span regions so if i think about what this looks like i have a subscription so i purchase an azure subscription maybe that's part of some kind of enterprise agreement or whatever else so i think about hey there's this subscription boundary then from a subscription i can use one or more regions so i'm going to pick a particular region that i'm going to create my virtual network within so that's another boundary and then i can go ahead and actually create my virtual network so i create my virtual network with one or more ip spaces so i can create that virtual network more than one ip space doesn't have to just be one so if i actually jump over to the portal so here we can see hey i'm just looking at the regular azure portal if i actually go over and look here i've got virtual networks on the left and i'm going to say add i have to as always pick a subscription pick a resource group remember a resource group is not a boundary of usage i can put the network in one resource group but connect resources to that that live in another resource group the resource group is the there for manageability i give it some kind of name so v-net one obviously you'd have a proper naming convention you wouldn't call it v-net one and notice i have to pick the region it exists in so i picked the subscription and i've picked the region then i pick the ip address space now by default it selected a slash 16 so think of it that's the size of a class b network so this is kind of a the subnet mask of 255 255.0.0 notice i can add multiple ones though i could add another ip space in here maybe i want to add in that ip space i could actually add in ipv6 address spaces as well though is it selected one by default for me and all of these ones that it's automatically added it's looked at my subscription and it's detected that hey you're not already using this space so it's trying to protect me from my self it doesn't want me to create vnets with the same ip address space because then i couldn't connect them because they'd be overlapping so it's trying to protect me from myself but i can add lots of different ip spaces to this network if i wanted to so i can add all different things into here really whatever i wanted to do and just kind of leverage these so you would go ahead often your virtual network would just be one ip space you don't typically have a whole bunch of these but i can even add these after the fact you might for example have an existing virtual network you already have and i can go to my address space and i can add additional ranges now if i've already done things like peering if i have other connectivity it will stop me because there's already some um exchange of ip spaces happen there's been checks to say they don't overlap so there will be times it will stop you but if i don't have those types of connections i can absolutely go ahead and add additional ip spaces post creation so i think about hey i created a subscription within a certain region so if i'm using multiple subscriptions i'll need a virtual network per region per subscription so if i have two subscriptions and in each subscription i'm using two regions well that's going to be four different virtual networks i'll need every sub would need a v-net per region that sub is using and then what i do is i break that virtual network up into subnets exactly the same way i do as on prem i don't just have one giant ip space we break it up into subnets so we can manage things like broadcast ranges a break up on when it goes to a gateway to go to other networks etc so we do exactly the same thing i can think about okay well i have my v-net of a bunch of ip spaces and then essentially i will break that up into subnets so i'll take a portion of that ip space and i'll kind of create subnet one i'll take another portion of that ip space and i'll create subnet two and and so on on so on so i'm essentially breaking up this ip space into smaller chunks and i'll put things in there now the important thing to note about these these subnets are regional as well the virtual network is regional the subnet is regional and why that's important is if i'm using things like availability zones i can think about how this one region but then to my subscription what actually kind of happens is i get projected three different availability zones an availability zone are essentially three facilities with independent calling power communication so it gives me some resiliency so this region it may be made up of three different azs az one two and three within my subscription subnets are not bound to a particular availability zone they still span across them now in my architecture if i'm using a zonal network service like a nat gateway then i would need to make sure when i put resources in the subnet we only put resources in this subnet that are in az1 if i have a nat gateway in az1 and i want to keep the alignment of my resources that's a more advanced concept that may not fully be clear right now but just remember that a subnet is not linked to an availability zone if you need to do that you'll have to make sure in your placement of resources you align it based on what resources you put in and what az they are in subnet on its own it spans those availability zones they are regional just like the virtual network and that subnet is a portion of the ip spaces of the virtual network it can't be a different set of ip spaces it has to come from the virtual network's ip space so again subnets regional they span the availability zones now i do quickly want to point out when we create the subnets ordinarily you create a subnet as a certain slash some size and you always lose two ip addresses you always use kind of the all zeros which is the network address and you lose kind of the all ones for the host portion as the network broadcast address but you also lose another three in azure um the first one is reserved by the azure default gateway and the next two are reserved for dns purposes so whatever subnet size you create you're always going to lose out of that size five ip addresses so for example if you created a slash 29 well you you're only going to have kind of three usable because azure's taken a whole bunch of them so normally a 29 would give you eight usable ip addresses well it would give you six usable ip addresses because you lose the first and the last well we'll actually have three usable ip addresses because again azure is taking them if i go and quickly go and look at my networks let's see if i can quickly find one where i have a really small subnet we could kind of see that in action so here you go tiny subnet you can see i actually did down here a slash 29 and you can see i have three ip addresses available if you look at kind of any of the others you can see hey i have 251 available you can see never really more than 251 because again you're losing the normal two you would lose and then three more so you normally the slash 24 has 256 addresses you lose two for that network and host leaving you with 254 then you lose another three for the azure gateway and then two more to map dns ips to the virtual network space so just when you think about sizing your subnets make sure you remember that hey azure is going to always take off five the two you're used to and three more okay so we have now these networks we have these subnets now what do we what do we do with these things now the ip address always comes from the fabric so if i think about okay well i want to create resources i want to use these things on here i never configure the ip address within the resource itself there's one time i do in an advanced multiple ip configurations per nick but ordinarily it's always going to come from the fabric and i mean azure there so inside the guest os be it linux or windows it's using dhcp dynamic host configuration protocol basically it shouts out on the network hey can someone give me an ip address and then azure will respond and based remember on the ip address of the subnet so essentially what i'm going to do is i'm going to put a virtual machine i'm going to place it in a subnet the reality is actually i place a nick a network interface in the subnet connects the nic to the subnet and then connect the nick to the vm but to all intents and purposes i'm kind of putting the vm in the subnet this will get an ip address from the subnet it's placed in if i de-allocate that vm and start it up again it might get a completely different ip address the next time but it's always kind of using that dhcp and azure's tracking ip addresses it's already given out and we'll give it out an available ip address the first one generally you're going to see given out is a dot four because remember the first four i lose for azure and just regular ip so i'll see a dot four if it was a zero network mask um that would be the first one i ever see given out to a resource so i connect it into the subnet now you might be saying okay dhcp that's okay for some things but i have resources like a sql server like a domain controller they need the same ip address there's some countering to that statement to say use dns names but then dns lanes have a time to live some things need to use ip especially domain controllers and dns i want to use that as a dns server i can't use a name i need an ip address so i can reserve an ip address using azure resource manager essentially at the fabric level like a dhcp reservation i say this network interface should always be given this particular ip address so even though the guest operating system says hey i'm using dhcp dynamically give me an address we're telling the fabric azure hey when this asks for an ip address i always want to make sure you give it the same one every single time and we can see that on the properties of for example a virtual machine so if i jump over for a second just look at any kind of vm i'll look at a virtual machine a domain controller i can look at its networking and what i can do is i can look you can see here the networking of the virtual machine is actually tied to a particular network interface that network interface has one or more ip configurations in this case just one and i can see hey on this it has a particular private ip address and what we can actually do is if i select the network interface we now open the properties of the nik itself i can look at the ip configurations over here in the settings if i select that then i can actually look at the ip configurations we're digging through a whole bunch of things here and now we'll see hey is the assignment of the ip address dynamic or static so mine is static and i've set the ip address so that's how we make sure resource always gets the same ip address at the fabric level i configure that and i can do that through arm templates through powershell generally not going to do it in the portal you also see this ip folding option this is typically if you have some kind of virtual network appliance that's going to receive traffic it can afford it on like some sort of gateway firewall device most of the time we're not going to use that for regular virtual machines but that's how i can configure a resource to always have the same ip address which is something that's going to be super useful if it is one of those special types of resources that can't have its ip address changing so we can absolutely do that so vms can be configured with multiple nics ordinarily a vm just has one nick i think about hey yeah um i i've got my vm it's got one nick that nick is connected to a subnet but there are scenarios you could imagine if i just draw out for a second maybe i've got multiple subnets let's just draw a two for now subnet one and subnet two i remember i said the reality is vms don't live in a subnet a vm is a resource and then what we do is we attach nics to the virtual machine now in this case i might attach tunics to the virtual machine and then we connect nics to subnets so if this vm was actually running some kind of network virtual appliance i might want it connected to multiple networks so i can actually say hey this nick here well you're going to connect to subnet one this nick here you're going to connect to subnet 2. now those subnets do have to be part of the same v-net i cannot take a vm and connect it to multiple virtual networks today so yes i can have multiple nics i can connect each nip to different subnets and i can have more than two depending on the size of the vm they all have to be in the same virtual network i cannot span virtual networks today as a single virtual machine that doesn't mean i p traffic can't flow ip traffic can flow between virtual networks by connect the networks but a particular virtual machine can only have nics connected to subnets in the same virtual network so here this vm is now got ip addresses in each subnet and could actually be used to maybe do kind of traffic inspection enable connectivity between them it could be an actual appliance that's now connecting so that's why you can have the idea of multiple nics for a single virtual machine maybe that's like a dmz internet facing and then internet so it's doing traffic inspection um rather than just letting that traffic flow directly through so i can absolutely have multiple nics on a virtual machine and i can have multiple ip configurations on a particular nic things like kubernetes clusters does this if you look at a kubernetes worker node you actually see in its ip configurations on its nikki has multiple ip configurations to handle all the particular types of networks that it's internally running for the various pods etc so again each nic can be in different subnets but it has to be in the same virtual network model ip configurations each ip configuration has a private ip and optionally can have a public ip so you probably saw when i was showing you that config there was kind of a public ip option as well now i'll talk more about this later on but essentially the nick has a private ip that's an ip address from the ip space of the virtual network sometimes you hear this called like a dynamic ip it's allocated from here i can also give it a public type so public ip is internet routable we generally don't like to do it i generally don't want to give a vm directly a public ip address it's better to use something like a load balancer a gateway a firewall in front of it rather than having some direct internet connectivity directly into a virtual machine but you absolutely can as part of the nik configuration in addition to this nick getting kind of that private ip i could spell from this sub there i can also allocate is called an instance level because it's at the instance of the vm public ip now when i do this the vm does not know it has a public ip this ip address i configure is not known to the vm the public ip is still kind of owned by the azure networking magic that's going on but what it will do is any traffic that comes into that public ip it will just pass straight through to that network interface so the vm knows nothing about this ip address but it will just process it via that network interface card so in terms of like network rules it will be network rules through to the private ip that would actually govern that traffic flow so for each ip configuration i have a private ip and i can optionally add a public ip again really don't recommend adding public ips directly to virtual machines it's a single point of failure it's much better to think about hey if i want to offer a service publicly most likely i'm going to want a resilient service and then some kind of load balancer to distribute those requests coming in among multiple vmware vm crashes the vms having maintenance that service still continues to be offered where you tend to see this a lot is hey i'm setting up a virtual machine i don't really know what i'm doing i want to be able to rdp to it from the internet or ssh on the internet i'll give it a public ip and then i can connect to it it's terrible and i'm going to talk more about this the portal used to do this by default i don't think it does it anymore it will just give it a public ip because it has to assume don't really know what you're doing you're going to want to connect to your virtual machine but i really don't want to just stick rdp and ssh on the internet i'd rather connect via some private means some bastion something else where i might do this public ip maybe i want to set up some kind of sftp server something like that and it's just a single instance but even then some kind of gateway and some firewall would probably be a good thing but yes you can do it in terms of the types of traffic we can have on a virtual network so order the standard ip based protocol so ip is layer 3 when we think about our stack ip is layer 3. so tcp udp icmp will work within a virtual network when you start going outside this things may work because it's still sitting on ip but then some other things like load balancers may not support it load balancers understand it's a layer 4 construct so a load balancer understands tcp it understands udp if you go and start doing like sctp it doesn't know what that is it's probably not going to work i cannot do multicast i cannot do broadcast i cannot do ip and ip encapsulated packets i cannot do gre because behind the scenes this is what's important to understand the virtual networks in azure are software defined networks these are not vlans this is software defined networking this is using encapsulation this is using gre to ensure isolation between different virtual networks and different tenants so i can't do gre on gre so this is all software defined networking this is not a separate physical vlan there's no layer 2 going on here this is iap software defined networking providing that isolation you can't ping the azure gateways they're not real again it's a software defined networking construct i can't use necessarily things like route to go to that gateway i can't use a network sniffer in promiscuous mode promiscuous mode means hey just give me every traffic on this subnet there is no traffic floating around the subnet really behind the scenes it's all direct via the virtual switch on the physical host so i can't go and sniff traffic for other boxes i can't just go and sniff the subnet so traditional layer 2 vlans are not supported there's no concept of that in azure the v-net is your isolation now i can do things like network security groups i'm going to talk about to control flows of traffic but the vlan that virtual lan concept there's no there's no equivalent in azure necessarily a virtual network is that unit of isolation so what about ipv6 uh we've run out of ipv4 addresses and we're being really greedy every fridge and dishwasher has an ip address these days so ipv6 is galloping in to save us so as i showed on a virtual network on a subnet i can enable ipv6 it is dual stack what i mean by that is i cannot just do ipv6 a virtual machine for example i can dual stack enable it but i have to have an ipv4 the azure management the health probes they use ipv4 so i still have i have to be dual stack ipv4 and ipv6 i cannot just be ipv6 but i can just like the ipv4 address ranges i can define ipv6 address ranges for both the vnet and the subnet it's also supported in things like network security groups user defined rules to control routing load balancers peering all of those constructs work across ipv6 things like virtual machine scale sets they work with ipv6 now aks the azure kubernetes service has some challenges today with ipv6 there's work going on it obviously kubernetes is an open source offering with lots of contributors that has some work to do around this but again that's going to be kind of a dual stack so again it cannot be ipv6 only as i said i can enable ipv6 for existing resources so if i have a vm a nic there's an ipv4 i can go and turn on ipv6 now i may have to reboot the reason i have to reboot really depends on the os because it has to now go and also check for an ipv6 address so that's dhcp and whether or not it requires a reboot to kind of give it that kick to go and check now for an ipv6 address today express route which we'll talk about but that's the way to connect on-premises to azure in a private way does not support ipv6 that is ipv4 but i can absolutely have public ips public ips can be ipv4 they can be ipv6 i can create a public ip and say both i can create prefixes so i can have kind of that path through from ipv6 from the public to my network through to my resources one point to note that when i create subnets when i assign an ipv6 address space to a subnet it has to be 64. with ipv4 because we're running out and everything else you pick the number of bits used for a particular subnet for ipv6 we're really not expecting to run out ever i think there's thousands and thousands of ip addresses per square foot of the earth so i think we should be good i think um but because of standards because of interoperation with other technologies 64 is kind of considered the smallest block we'll use for a subnet which sounds crazy in a way that hey a 64 is the smallest we're going to use for a subnet given the ipv4 the entire address space is uh smaller than that but there you go when we create subnets we'll create them as slash 64s in size it has to be exactly can't be bigger can't be smaller every subnet will be a 64. okay so about external access now i talked about well i can i can give things a public ip address but i also said we generally don't want to do that if i have an on-premises location and i want to use things in azure i don't want to go out by the internet and back in again now there will be times i want things in azure that are public facing some web-based service absolutely that's where i would use a public ip address on a load balance or gateway that goes and talks to back end services but if i want to use those azure resources from my network i don't want to go out by the internet now when i do talk about things in azure being available to the internet there is no special dmz where i get public ip addresses essentially every subnet in azure is created equally any resource in any subnet can be given a public ip address so i could think about okay i'm going to create a load balancer maybe i have a bunch of resources in this subnet and i can absolutely go ahead and create like an azure load balancer that's external facing so it has kind of a public ip and it would then as a back end set talk to those virtual machines so that's where that load balancer has the public ip but likewise i could give that nick here allocate a public ip to it i could give one to that one there's no special subnet that is externally facing i could give anything a public ip address i wanted to that does not mean i have to have a public ip address to talk to the internet this is about hey something is out on the internet and i want to be able to offer services to it so i want people to come this way and make requests the services i'm offering in azure so i have to have a publicly routed ip addresses that people on the internet can talk to they probably resolve it from a dns name and then it resolves to stuff but if i'm in the virtual network and i want to go out to the internet i do not need a public ip address i do not need to be in a special subnet i can automatically access the internet behind the scenes azure will enable um snat and peanut depending on what i have so i can get to the internet and it's stateful it will let the response come back to me if i'm a resource that has a public ip address then it will use that for me to get outbound to the internet so that's the public ip that will be seen from the internet when i make a request if i'm on virtual machines behind a load balancer if it's a basic load balancer and it has a public ip i'm going to use the public ip of the load balancer if it doesn't have a public ip it will automatically get kind of allocated one and i will use the load balancer if it's a standard load balancer not basic if it has a public ip i will use the load balancer if it does not have a public ip they won't have any access to the internet i'd have to do something else either i add an external facing load balancer that has a public ip and i can do outbound rules or i could add like a nat gateway to the subnet and use that for outbound communications if the vms are not behind a load balancer and don't have a public ip azure will automatically allocate a public ip address to provide them access outbound to the internet it will do that source network address translation the port address translation to enable them to get to and receive the responses so i do not have to do anything for things to talk outbound to the internet and get a response i can block it if i don't want them to be able to do that then i can use their security groups to control that flow i could do routing changes to redirect where requests to the internet would go to but by default i don't have to do anything i can deploy vms they can go and get to windows update or anything else to to get those internet based resources there's no special kind of dmz subnet i have to worry about so by default azure provides that stateful based connectivity to just allow the response to come back but to provide services to the internet right you have to give it an instance level public ip which we don't like remember the bad thing is it's avm has that public ip if that vm goes down blue i placed them behind a load balancer a gateway a network virtual appliance that has the public ip to make it more resilient um use a network virtual appliance with a public ip so i have those different options really take care of what you expose to the internet if i am going to offer services outbound to the internet so hey i want to offer something most of the time what we're going to be offering is things like 443 i want encrypted traffic to come in that's all i'm going to accept i i probably don't want to just open up rdp ssh winrm if you do that it's a great way to test how good your passwords are because you're going to get hacked there's constantly scans going on it it's going to find that hey there's this opening for rdp and ssh you can change the port and try and be clever and try and obfuscate it it won't work they'll find it because they use port scanners and look for responses and they're going to attack it now i totally understand there may be times i have to connect to it from the internet i don't have private connectivity set up yet this is kind of my my only option if we are going to do that there are ways to do it securely or at least more secure there are things like just in time access with just in time access i'll show this quick what i can actually do i'll jump over to this vm so what we have here is as we look at this i've i've enabled this is part of security center so if i go to security center we can see i've got all these different solutions if i look at azure defender i have various options here but one of them is just in time vm access and if i look at this it will show me the vms that have public ip addresses and where i've basically enabled that connectivity to so what this does is rather than just always having some opening to the internet what i can do is hey look when i want to actually connect i can go to the resource and i can say hey i want to connect but it's going to tell me hey first i want you to open up using my ip only i'm going to request access and then depending on my configuration it will open it up for an hour or two hours but it's only from my ip no other ip on the internet would actually be able to connect to now obviously if i'm sitting in mcdonald's or starbucks on their wi-fi i'm sharing their outbound public ip so if i'm really unlucky someone else sitting next to me tries to kind of connect to my vm at the same time that's pretty unlikely and again it's only open for a small window of time so if i have to open things up to the internet for rdp ssh you can use things like this just in time protection go in and say hey i want to open up access to my public ip for a limited window you could manually go in and set up a network security group world look up what your public facing ip is add that as an exception and then remember to disable it but the danger there is you forget to disable it definitely definitely don't just open up internet facing um it it's probably going to be a bad day okay so we talked about how we can enable connectivity to virtual machines and yes that is one option for how i could get to things from on premises what we're going to talk about in a second is the idea of that private connectivity from on-prem to things in azure but first what about connecting virtual networks together remember if we have multiple subscriptions if we're using multiple regions we're going to end up with multiple virtual networks and i know i talked about kind of putting a virtual machine in a subnet but many other types of services use virtual networks i mean virtual machine scale sets which is automated deployments of vms as a kubernetes service those worker nodes of vms and lots of app services can go and integrate with the virtual network since many many times we're going to use virtual networks nearly every type of architecture will use a virtual network so if i have multiple subscriptions multiple regions i'm going to end up with multiple virtual networks and a lot of times i might want them to connect to each other now in the past what we would do is we could kind of use a site-to-site vpn or we could connect them to the same express route circuit so i could think about well i end up with multiple virtual networks this could be because of multiple subscriptions it could be multiple regions could be a combination so i could think about hey i had this subnet i had this subnet i had this up there i'm saying something i mean v-net so i have four different virtual networks and to connect them one option was site-to-site vpn when i use site-to-site vpn i essentially have kind of a gateway subnet in each virtual network in that gateway subnet these automatic appliances are created for us to act as the gateways so in this gateway subnet i actually have gateways and what i would essentially have to do is create site-to-site vpn connections between them if i use um the the route based um i can have multiple connections so i could have hey i'll have a connection to that virtual network and a connection to that virtual network and hey i'll connect to that one as well well this one could add i mean i could i could create these sets of connections but obviously i'm restricted to the performance of that gateway set of appliances in there they have a certain bandwidth so even if these virtual networks were in the same region and they could kind of see each other from a software defined networking perspective the bandwidth would be restricted to whatever those gateway appliances could actually do and i i picked the skew when i create those another option was well instead of doing kind of a site-to-site vpn and connecting them to each other the other thing you could kind of do is well i still have these multiple virtual networks they're all still there but what i can think about is here we have these this big azure backbone network and what i can do is there are these things called meet me locations they're peering points and ordinarily and we're going to cover this later on this is very useful if i have an on-prem network i extend my network to this peering location well this now gives me connectivity to things connected via that and what i would very commonly do is say this virtual network i can do something called private peering so the private hearing will say hey this gateway is essentially going to give me connectivity through this so it would essentially give me a connection all the way through well if i connected multiple virtual networks through separate gateways to the same circuit so i can kind of imagine for a moment i have a particular express route circuit i can have multiple connections to that circuit so if i connected multiple express route gateways to the same express route we'll actually just call this a particular circuit here for the same meet me well they could actually talk to each other now the traffic will happen by the meet me location so if you think about that for a second let's imagine just for the sake of argument these were all in south central us and i had multiple virtual networks maybe it's four different subscriptions and then imagine i my facility is in dallas so my meet me location is in dallas as well i want it kind of close to my facility it then gets as quickly onto the azure backbone network so if i took this approach to connect the virtual networks together when this virtual network wants to talk to that network even though they're in the same physical facility for them to talk that traffic would bounce fire the meet me location in dallas where it would then be sent back up so you can think about from a latency perspective that's really not that great so yes there are things we can do i can put them on the same express route circuit but then they have to talk via the peering location i can use a site to site vpn but now i'm using up the bandwidth capacity of those vpn gateways so that's not really a great solution either so what we want to do is virtual network peering virtual network peering lets me connect virtual networks in the same region or different regions with global v-net peering there is a small ingress egress charge for the data i pay for it going out of my v-net i pay for it coming into a v-net but this now is all on the backbone azure network it's whatever performance those virtual machines are capable of now the ip addresses cannot overlap i cannot overlap those ip ranges and expire them together how would it route this can span subscriptions it can span azure 80 tenants the peers are not transitive but they could be so if i go back to this picture we kind of agree this this is not a good thing i don't want to use outside i don't use express route so imagine for a second let's just say i have kind of a hub main v-neck and then i've got let me just say two others for the sake of simplicity i have kind of a a spoke av net and a spoke b v net there could be different regions different subscriptions different tenants it doesn't matter i can set up peering so i set up v-net peering between them again the ip space cannot overlap they have to be unique ip spaces but now resources in here can talk to resources in here resources in here can talk to resources in here without doing anything else and operating at the full band with the full capacity of whatever that resource that nick that vm size it's just going over the azure backbone locally the network spoke a cannot talk to spoke b it is not transitive just because they trust the same hub does not mean they can speak so this communication does not exist if i want them to be able to speak directly well i have to add appearing relationship between them as well so i have to go and do that and so i could create essentially a mesh now there is other options around this if you did azure virtual wan and i covered this in a separate video it automatically enables these to be transitive by doing something special in the hub so let's talk about what i can do but remember by default if i do nothing else it is not transitive but let's say i don't want to do this i don't want to have to set up all these separate peering relationships so what i can have in the hub and we kind of referenced this earlier when i talked about network virtual appliances i can set up some kind of appliance this could be something like azure firewall this could be a network virtual appliance from the marketplace i'm going to combine this with something called user defined routing what user defined routing does everything in azure the reason these ip spaces can't overlap is it exchanges routing information it works out a route table and what i can do is i can say well let's just we'll throw out some my p spaces let's say for example this is 10.0.1. 24 and this is 10.0.2.0.24 and we just call this 10.0.0.0 24. what i want to be able to say is look if you're in spoke a if you want to get to spoke b you need to talk via this now this appliance here will forward traffic it knows its job is to maybe inspect but then forward traffic on so we could say well this thing has an ip address 10.0.0. we call it 10. so what i can do is i can create a route table and a route table enables me to say for this particular ip space this is your next hop next hop means this is where you send the traffic to that's the next place it's going to go so what i could say is i could have a route table in here that says hey to get to 10.0.2.0.24 you need to send the traffic to 10.0.0.10. so if i'm trying to get to something that's in the 10.0.2 network i'm just going to forward it to this resource this resource knows hey i'll forward it over to there you could think about this could be one of those vms with multiple nics and there's other ways this can be done on this network i would create a route table that says hey to get to 10.0.1.0 24 i this address space once again i send it to 10.0.0.10. you'll notice it's kind of this dot 10 network it doesn't have to have a nic in each network there are some types of appliance that will you don't have to the next hop does not have to be in my subnet that's a great thing about software defined networking it can kind of bend some of those rules that we're used to in a physical networking world so what i've done is even though peering is now not natively transitive it will then route by this appliance now you do have to consider with azure firewall if doing the job it automatically scales you're not going to see a problem if i was using a network virtual appliance remember if i'm doing a lot of traffic it's gonna go that applies essentially one or more vm it's probably multiple vms behind a load balancer it has a certain capacity so i'm doing a ton of traffic just make sure you're scaling that nba solution the right way so we can handle whatever i'm throwing at it so just make sure you scale all the components kind of the right way this peering is very simple to set up again i've got a separate video on this but essentially i set it up that way and then this way now if i have permissions in both virtual networks i can just create it in one go additionally i actually have to have a permission if i let's say i'm this network administrator i can't just create a peer to this virtual network i can't even make the request there's a limited permission that i need to actually connect to that virtual network and the documentation goes through all of them you can create a custom role i've done it for some of my customers which just has two actions in it there's like a peering action request and that's better to see the network so i can create a custom role that lets me appear this way and then i would give these network admins the same role on my network so they can appear that way so we can complete the peering relationship but essentially i need permission to kind of lasso out to that network and then they need the same to come back to me again if i'm a permissions on both i can just create it in kind of one go but now i've connected these networks together and and i can go one step further imagine for a second when we talked about hey i kind of got maybe on-prem and i talked about hey there's this great big azure backbone network that kind of azure is connected to all the regions this is within a regional mob regions but in this one we have kind of this subnet gateway and we have the gateway appliance for express route so if i had kind of an express route connection in this hub network that was connected to my on-prem and i had private peering set up i can actually do something on these spoke networks i can kind of say hey look i want you to use remote gateway so they're now going to use the gateway of the network they're connected to and on this one i'm going to allow gateway transit i'm going to allow them to actually come and connect in and use my connection so now i have one gateway but my spoke networks would actually be able to use it so that's a great thing about peering that i don't have to now connect all of them to express route i can just have that one gateway and that gateway cost me money this is a good thing either one gateway i can control the traffic that's coming in i can inspect it it has the connection by the the meet me the peering point and then my spokes can use it so this is a super super common pattern you'll kind of see time and time again but that peering is is really key to lighting this up so i mentioned express route i mentioned site site vpn a couple of times now so let's let's dive into that a little bit let's actually think about connecting to on-premises so yes we talked about internet facing we talked about how we can give things a public ip i don't want to do that that's not the way i want to give access to things from my on-prem just to go and use things in azure i want to think in a lot of ways about extending my on-prem network so azure is just part of it i want to be able to connect to things over those that private network so a number of ways we can connect to things in virtual networks from on-prem i can do a point-to-site vpn so we have this idea that i can download a vpn client and then if i'm just an individual machine for example i could hey i'm a my machine over here it's just me i can light up a point to site vpn connection so point the site means i'm not connecting an entire network my machine will be given an ip address from a pool that the vpn so the vpn is different from the express route gateway it's a separate gateway but i can have both as long as the gateway is up that's big enough this machine gets a connection to this network he gets an ip space from a pool that's reserved for point-to-site vpn so if i had individual contractors that just needed to get access to the v-net and anything ph to it connected to it i could do a point-to-site vpn i could do a site to site vpn so a site site vpn as the name suggests is connecting an ip space of a network to azure so in this case i could think about when instead of this express route i have some location over here they have kind of a vpn device and that vpn device is going to establish a tunnel so it's going to be ipsec tunnel this gets known as an ip space to here so now anything on this network can now talk to anything on this um and if it's kind of that the the route based not static it can go and talk to all of the other things as well so if i have some location maybe express rat doesn't make sense for me maybe express throughout is is too expensive i can use site site vpn hey i'm just going to go and connect my ip space on pro to my virtual network so that's absolutely an option now this siteside vpn gateways there's different types of them and again i want that route i think i said policy so you want that route base lets me have multiple connections policy is static it's route base is dynamic it kind of exchanges lists of routes so there's a whole bunch of these different gateways so if we take a quick look at this here we can see if we scroll down for a second so i can see there's base it kind of don't really worry about basic that much but there's like vpn gateway one two three four five you can see the bandwidth changes depending on which sku i buy so the higher the skew well the more bandwidth i get you'll also notice things like the number of site-to-site tunnels goes up as well hey look there's 30 maximum instead of 10 and number of point-to-site connections that's variable now you'll notice where it says things like 1 to 10 again that's if it's kind of that route based not the static policy point-to-site vpn also requires you to have that route based that's not going to work on policy and then there are some that are a z resilient so those gateways actually there's multiple instances you can configure them to run inactive active both with the az and non-az and it will actually distribute them over multiple availability zones so i have resiliency from any kind of single data center failure so i can go and select these i would pick the one that makes the most sense based on what what is the bandwidth i actually need obviously i don't want to pay for more than i need i want to make sure i'm hitting that amount of actual traffic so again i want to use the route based if i can it's going to depend on your hardware probably on-prem with the route base it exchanges the list of ip spaces whereas the policy is static and it's a lot more limited i can just have one connection and i can't do the point-to-site vpn on that then we have express route and express route would be kind of the the roles voice siteside vpn goes over the internet it's ipsec encrypted so it's not really a security problem but it is going over the internet so yes i'm encrypted but i drew a straight line but it's really not a straight line i'm probably bouncing around different gateways there's different delays there's latency latencies who knows it's going to be variable because i'm just bouncing around the internet whereas express route is a private connection i'm not bouncing around the internet express route gives me a connection once again via a gateway when i'm using this private peering i talked about this earlier i can have a circuit with multiple connections so even though i've got one express route circuit i can actually connect it to multiple virtual networks now again yes they can talk to each other by that but it's going to go by that peering point they're going to get that kind of latency most enterprises will leverage express route because it's that dedicated connection it's a private connection it's not going over the internet and the latency will be lower and it will be consistent i have a particular path and i'll always be taking that path there are different types of express route so i drew kind of these lines this could be kind of thought about like an ethernet so i've got my physical location i get a connection by a provider to the meet me and then microsoft's network this big backbone has been extended to that meet me then on that network i do private peering so private peering is connecting my network to a particular virtual network using that gateway it's not encrypted it doesn't need to be because well it's not going over the internet it's a private connection if you want to you can you can combine things like site to site vpn and express routes you can do a site site vpn over the express route connection so then it is encrypted there's capabilities at the provider here you can do mac sec so mac set would encrypt the traffic between your you have basically an edge router and then microsoft has edge routers in between that's going over kind of the air space of this meet me this carrier neutral facility and max that will encrypt that traffic between your edge router and microsoft's edge router but it's not doing an end-to-end encryption you would have to go and do that if you wanted to generally most most companies don't they don't need it as a private dedicated connection to you now if the service you're accessing over that is https for example it's encrypted anyway if i'm using smb3 with encryption it's encrypted anyway but now i have this dedicated connection the latency will be consistent and it will be really as low as possible you pick a meet me location close to your data center let's get you on the microsoft backbone network as quick as possible which is super fast and it's going to get you into those regions now super important about express route you are not connecting to a region with express route expressway is connecting you to the microsoft backbone yes there is a region that's probably closest to that and there is a sku called express route local where i don't pay egress over here but i can connect to any region in the geopolitical boundary so if i have a express route circuit and i've chosen dallas i can connect to east us west u.s north us it doesn't matter i can connect to canada if i create one in europe i can connect to any country in europe if i do express route premium then i can connect to regions outside my geopolitical boundary so don't think express route is connecting to a particular region it is not express route connects you to the microsoft backbone network and then over that i can do private peering to particular virtual networks in regions within the geopolitical boundary or even other geopolitical boundaries if i do express route premium and i have like an hour and a half express route deep dive where i go into way more detail than probably you ever want to know but if you do go and check out that video it's got everything in there now i do want to point out this traffic is going by the gateway so that gateway is a certain spec there's something called fast path if i turn fast path on it's only available on i think that the 10 gigabit per second have to check that the traffic does not flow via the gateway the traffic essentially comes in and goes to the resource you you're removing some of the latency you're removing maybe even the fact that this 10 gigabit second gateway is too small there is still a gateway i still need the gateway to do bgp to exchange routing information have bgp sessions but the traffic does not flow via it fast path does not work for peering it would not fast path to other networks that appeared that would go via the gateway but express route would give me a dedicated connection there's also something called microsoft peering microsoft peering is about well there's other services in azure there's things like storage accounts there's things like sql there's all these other things ordinarily i access them via internet endpoints well i could make those advertised by my express route connection as well so now when i want to go and talk to azure sql database or azure site recovery or azure backup it will go by my dedicated connection instead of going by that public facing service now there are now other ways to achieve this with private endpoints and make these services have an ip address in my vnet and then i can access it via private peering but if i don't do that i can actually make services offer just using microsoft peering so we covered a lot of different things on this particular picture again we talked about kind of these route tables so you can use user-defined routing i don't have to use it just in this one scenario i can use user defined routes to really control hey i want things to take a certain route this is where traffic should go i can even black hole traffic um using a route table so you can go into azure create route table so there's different types of hops there's peerings there's nvas there's various things you can actually go and do with that but i really can completely control how my traffic flows now one other thing before we move on to kind of controlling the traffic is for the express route i drew this kind of direct connection it was kind of this ethernet and exchange provider there are other models if for example maybe today i had multiple locations and my multiple locations were currently connecting using something like a an n e to any an ipvpn like an mpls if i had an mpls today well i can actually add my mpls to a meet me location to essentially connect it to the back end i might actually host services at one of these carrier independent carrier neutral facilities a colo who might have a connection so there are different ways to actually get on to that express route but essentially once you're doing that you're getting that direct connection to the microsoft backbone and then i can connect to regions and other types of services so it's about controlling the traffic flow we've enabled all these connections network to network network to on-prem by default the traffic will flow freely within the virtual network it will throw freely to peered networks it will flow freely via my express route my site-to-site vpns any connected network is gonna flow if i want to control the traffic then i have to do something to control that there's different methods i could use that like azure firewall or a network virtual appliance to control the flow of traffic this is where i would use kind of a user-defined route a route table to say hey the next hop instead of maybe going via default to some gateway or the network always go via this appliance that appliance could then check it could maybe do even packet inspection before allowing it through we can use network security groups application security groups service tags and this is just part of azure this is a very popular option it's not an edge device so a network security group is essentially a list of rules and i can either allow or deny the traffic now i can apply this at a nick level of like a virtual machine or the subnet but the reality is the way the nsg actually works is if we think about okay i have my virtual network so this is my v-net and then i can think about well i divide that up into subnets and then within that subnet remember i essentially create vms which are really connected because the nic is connected to the subnet now when i create a network security group remember my network security group my nsg is really comprised of saying hey i have source destination kind of protocol port and kind of my action am i gonna allow it or deny it and often these sources and destinations are kind of side arranges groups of ip address now i create these one or more rules that make up the network security group and i apply it now if i apply the nsg at the subnet or the nick the enforcement is the same this is not an edge device sitting at the perimeter of the subnet if i think about the way networking works i can think well there's kind of a hyper-v box which is what runs azure in there there's kind of a virtual switch and then there's a virtual filtering platform as part of that switch and then you have the vms in this virtual filtering platform that is where the nsgs are enforced as the traffic kind of goes in or out of the nick so it doesn't matter if you apply the nsg at the subnet or at the vm level it's always enforced at the neck the nsg management of the subnet just makes it easier to manage there's zero benefit in putting nsgs on the nick and the subnet you're not giving it double protection it's just enforcing the same rules twice as the traffic goes in and out of the nick so i create these nsgs and i generally best practice i apply at the subnet level so it's easier to manage now those nsgs are normally like i say made up of these ranges of ip addresses so if we jump over for a second so let's take a look at this so if i actually go and search for nsg and i'll just look at one you actually see there are some built-in ones so i've not changed anything about this i can see there's inbound and outbound rules inbound you can see well any port any protocol source virtual network destination virtual network allow it now virtual network makes you think it's just the v-net it's actually not the virtual network is the virtual network and any network it's connected to this could be through peering it could be for express route any known ip space is the virtual network there's also one called internet internet is anything that is not the virtual network so just to be super clear on this if i go back to my whiteboard in this kind of picture here where i had my virtual network peered networks express route connected networks site to type vpn all of those ip spaces they are the virtual network it's known ip space not the ip space of the virtual network virtual network in nsg terms actually means known ip space so it's it's important to understand that kind of difference so you can see there's default rules here and these default rules basically saying hey look anything within the v-neck can talk to each other and the azure load balancer there's this special source name load balancer can talk to anything everything else inbound deny now these are the default rules you can hide the default rules you can see i have no manual rules defined then i have outbound rules and what this says look anything from the virtual network to the virtual network again outbound to anything within the known ip space is allowed anything outbound to the internet is allowed and this is stateful so the response will be allowed to come back even though there's no inbound rule from the internet it's a stateful service so nsgs understand hey i sent a request it will let the response come back everything else is denied now if i wanted to let something else come in well i can add rules here we can see the source ip address i could add a particular ip to allow in i can say what port it's coming from i can say the destination again i p addresses and then i could set destination port ranges with the protocols allowed and i and priorities surprisingly the lower the number the higher the priority if you want to maybe override a different rule maybe saying that's more specific so here i can have kind of yes i can do ip ranges but you see these kind of service tax if i select that there's lots and lots of different service tech you see all these kind of generic service tags here for example and then you'll see ones that are region specific so cosmos db key vault sequel storage so this essentially would allow me now inbound is not so likely with storage for storage it'll probably be an outbound rule so if i look to my outbound rule for example i might say hey from my whatever this is attached to i a subnet i might say hey from my virtual network or from maybe a particular ip range within my network i'm gonna allow it maybe to go and talk to certain storage again if i select one scroll down i can say storage in south central us for example so these are called service tags and to make this kind of easy if i jump over to actually some code for a second i'll just clear this away if you think about the azure public services are offered over a whole bunch of public ips so what i can actually do is if i run this piece of code i'm going to get a list of all of the service tags that exist and now i want to look at just the ones the storage for south central so it's showing me all of the ip prefixes and then i could actually go and list those out so when you use a service tag what this is really letting you do is i as a person trying to create a rule have no chance of getting the right ip ranges for storage in south central there's too many and they change so all a service tag lets me do is when i put in a service tag here for the source or the destination it's actually mapping to a whole bunch of ip ranges but it's microsoft are basically maintaining those they're maintaining those ip addresses so when i use a service tag in an nsg rule it's equating to ip addresses of some service so hey i could think about all of the storage services in south central us use a whole bunch of different ips those ips are what map to storage dot south central us which i can then use in my rules so the point of nsgs i create these list of rules and i then map them to subnets and again i can use ip ranges so i could say hey the ip range of this subnet is not allowed to talk to the ip range of that subnet imagine a scenario where maybe i let's say i have three subnets and let's say maybe in this one i had a bunch of front end resources that were internet facing maybe this is a bunch of middle tier resources this is back end maybe kind of databases i've got some kind of sequel in here so if nsgs i could create a set of rules that could say look this ip space at the front end well maybe from the internet it's allowed to receive 443. it's actually offering services to the internet and again i'm applying the nsg to all three subnets they're rules based on the ip range of each subnet i might say hey the front end is allowed to talk to the middle tier subnet the middle tier is allowed to talk to this one maybe only port 14 to 33 sql could control that and i could say the front end is not allowed to talk to the back end i can actually go and block that so the point of the nsg's is it lets me control the flow of traffic so it's super powerful but i'm really focused on blocks of iop addresses but you definitely definitely want to use these again it's not a physical appliance it's on edge device it's rules that get enforced in the virtual filtering platform with a virtual switch of the host running your services so i make them up with these rules i can also do something called application security groups so if i think about application security groups right now i focused on kind of ip addresses or service tags and that's great as long as i organize everything very neatly into subnets but what if i don't what if things are a bit more scattered around so what i can do is i can create a tag i could create a tag these are called application security groups i might call it sql vm or iis vm so now in my rules in addition to ip ranges and service tags i can say asg tags so i could create a rule that says hey sql vms are allowed to talk to middle tier vms middle tier vms are allowed to talk to front end or iis vms isbns are not allowed to talk to sql vms i can just put those in my rules instead of worrying about which ip subnet the resources are actually in so if we jump back over you can actually see that here if i go for my source you can see there's application security groups and then i could see the one so i've actually got one called sql vm if i look at my application security groups i can see i've got sql vm defined in east u.s sql vm in south central us web vm in south central us and quarantine in south central us and the way i use these is it's defined on the nic so if i go and look at one of my services i look at the networking notice on this network interface here i have app security groups so here i can just go and add various asgs that apply to this nic so if i use them in the rules well that would then be enforced i'd then be controlling it for those so that really simplifies how i can think about this you notice i had something called quarantined vms why did i have a tag called quarantine vm well imagine a scenario that you have some kind of health check going on i could have a rule that could kind of say look if my source is asg quarantine vm then basically block it unless it's talking to maybe a remediation set of resources and if my health detection detects a vm is unhealthy all it does is it goes and slaps on quarantine on the nick and i'm done just by doing that because all my rules that i've deployed and all my resources say hey if it's coming from quarantine slap this thing down only that it talks remediation resources i've essentially put that vm in quarantine just by applying attack to it so network security groups those app security groups are super useful and definitely worth investigating okay so service endpoints and service endpoint policies nsgs are focused on traffic in and out of the network and even with those service tags it was fairly broad it was storage in south central it was not a particular storage account many azure pass offerings including storage and sql have their own kind of firewall built in and i might want to be able to restrict that service that particular storage account that particular sql instance to only talk to particular subnets and that's the goal of service endpoints they make a particular service endpoint known to types of service then on a particular service instance i can say hey only allow this one through so if we go back to our picture here for a second you can imagine hey i've got this subnet and you can imagine hey remember we had storage but let's just say here i've got storage account one now with nsgs and this is maybe in south central us i could say hey only let this subnet talk to storage in south central us great now this account also has its own kind of firewall that's in front of it and i can say only allow certain ips through but that doesn't work here these are internal ip ranges there's nothing useful i can do here unless i want to try and make it go through some kind of exterior service and bounce back in nope even when i access exterior facing services in azure it doesn't go out to the internet and back it does stay on the azure network but it's not a direct path it kind of goes around the azure gateways a little bit but what i would like to do is say hey storage count one you can only be talked to from this subnet 3 for example but to do that subnet 3 has to be known the way i do that is i create a service endpoint for storage on that subnet it's going to do two things firstly now it actually creates an optimal route now it's not doing this more wiggly thing there's an it updates the route table on the subnet to now have a direct route as a next top of the kind of the service endpoint for the ip addresses remember those service tags that make up storage in south central us also now this subnet is a known entity to the firewall so it can be allowed or disallowed so if we jump over so what we're looking at here is firstly if i look at my virtual network and i look at my south central us and i can actually go and see service endpoints you can see i've got some enabled i've got for storage and i've got for sql so now if i go and look at a particular storage account in the region and if i go and look at its firewall instead of just being open to all networks i could now restrict it to selected networks and now add an existing virtual network pick that network and it will show me the subnets now show all of them but notice there's no endpoint required i already turned it on now it can do both steps for me it can actually go and turn on the endpoint if it wasn't already but i can now essentially lock this down so that any other access unless it's coming from this subnet would not work it will be locked down to now only that particular subnet that i have selected so what it's now giving me is that ability to say hey i don't care that it's public facing the only thing that's allowed to talk to it is the particular network or the particular subnet that i enable now it is important to note these service endpoints are not kind of routable and i have to create the service endpoint in every subnet that wants to talk to that resource if this v-net was connected to something else like an on-premises via express route this could not use that service endpoint it's only good for that particular storage account for that particular subnet okay so nsgs let me say only talk to storage accounts in this region okay or sql or anything else so it's endpoints with the firewalls the service they only let this subnet talk to this service the only gap is that i might have another storage account i have storage account two there's still in south central us so the nsg would still let me talk to it i'm on this up there and i'm a bad guy evil english accent probably am the bad guy and i could right now connect to that one from this subnet copy things and copy it to that storage account it's south central us i'm not restricting it to particular instances of the service so what we have then our service endpoint policies service endpoint policy says hey you are allowed to use storage account one and i then apply that policy to a subnet so now i can only talk to storage account one from the subnet i can't get the storage account too anymore so to see these here if i'm here in the portal if we just search for service endpoint policies you can see i've created a policy the definition i can say everything in a particular subscription everything in a resource group or just a single account i'm only allowing this particular storage account and then i take this and i would apply it to a subnet essentially then i'm locking down that subnet to just the service instances that i'm defining in that policy so those things together are really really powerful i'm using the fireball on the service and now i've locked it down to just particular instances okay that's great there's one more thing i want to talk about but before i do i want to quickly talk about dns virtual networks can use azure dns built in or custom in the network properties i can select use a custom dns and point it i do it mine i use my active directory domain controllers at a nic level i can override that so i can actually say hey this particular vm uses a different dns config from what the network this might be a special type of service maybe domain controllers they need a different config never ever set dns within the vm itself very bad things can happen if i need to override i can set it at the next level of the virtual machine now azure dns has both public so i can create zones available to the internet just very standard records kind of host records a records or i can have private dns zones private dns zones are very rich i create all different types of records and then i can link them to particular virtual networks but they're only usable within azure now if a private dns zone you pick the name you have full management of this thing now whether you know it or not you're already using a private dns zone even if you're using custom dns so by default there's an internal.cloudapp.net azure dns so that every virtual network has now if i go to my vm that's in azure i am using custom dns if i actually open up command prompt if i do an ipconfig slash all you can see hey yeah look i'm at the bottom here i'm using custom dns my domain controllers however azure dns is always available by a 168.63.129.16. never going to remember that it's one of those special addresses that's on every v-net so if i had an ns look up for one of my records if i did sav azure us south central um dc01 now normally it would be in my custom zone based on my dns servers but what if i look up this cloud app name if i do internal.cloudapp.net and i query the azure dns endpoint on my virtual network it it has a record there as well i don't want that i don't use that it is always there i i cannot turn that thing off that's the internal special zone that things are used internally i can't create records in there but it always exists so whether we want it or not we're always using actually a azure private dns zone but we can absolutely add more so these are a useful thing so i could think about hey i have my kind of virtual network and then i can create one or more private dns zones so i pick the name so i pick name.net is it all internal i can create all the different types of records um alias service resource text you name it i can create those types of records i have full manageability so i kind of create this zone and then what i do is i can link multiple virtual networks to it so i can link a virtual network to one for auto registration so these are now the vm names in here and i say vm names could be vm scale sets uh aks work nodes anything that essentially uses a vm underneath well now register vm.name.net but i can only link to one private for registration i can link to a thousand for resolution so i might have ten different private dns zones to other things linked to maybe i manually create records i could resolve name2.net name3.net name4.net multiple v-nets can connect to the same private dns so i can use these across regions even across tenants across subscriptions if i have the right permissions so i think i can have like a thousand networks can resolve from a v-net having a hundred can register too i think of the numbers check that i think that's right so i have multiple things connecting so i get consistent name resolution even between different um virtual networks why am i bringing this up um it's useful for one thing in your network if i'm using active directory uh honestly um i'm probably gonna be using that directly for my dns i'm probably not using this very much i remember i talked about that endpoint i talked about this kind of special address 168.63.129.16. that is always azure dns i don't care what eip space your virtual network is this is azure dns now it will only work from within a virtual network if i had an on-premises network that was connected express route sites like vpn whatever it could not use 16863129.16 if i wanted to use azure private dns from outside an azure virtual network what i could do is i could inside a virtual machine install kind of a dns resolver set that up to forward to that ip because it could because it's in the v-net and then configure things to talk to this ip address from on-prem or other networks so if i want to use azure private dns from outside the v-net remember i can connect multiple v-nets to the same zone if it wasn't something in azure i can set up a dns resolver why why am i even talking about this okay so i talked about v-nets one private oh there we go one private a thousand azure private link final thing we're gonna talk about so ordinarily i talked about those external facing services we can use service endpoints to get direct paths but it's still essentially coming in through the public ip i can lock it down with the service endpoints i can say only that subnet it's secure but some people still don't like the fact that it's coming in via a public ip address so private link lets me actually create a private endpoint into my virtual network i can also project custom services so remember this picture remember the storage account had public facing ips and i could use service endpoints to lock it down well what i could also do is let's have another v-net and remember that v-net as always has those various subnets for private endpoint this particular storage account sa1 i can tell it hey i want you to project a private endpoint into that particular subnet it now gets an ip address from that subnet i can completely turn off the public facing ip address it will still show if you do an ns lookup for the name but it's completely unusable it's now locked down to just that private ip so now things in the v-neck can talk to that ip address instead to get to that particular instance it's per instance the private endpoint ip is for a particular instance storage count one any networks that appeared to it would be able to talk to that ip any other networks that were connected to it via like a site-to-site vpn express route would also be able to get to it so as those service endpoints only work from the subnet this is an ip address it's an ip address in this ip space anything that can route to that ip address or can get to that service but there's one other part ordinarily your services have a dns link this was called storage account one and it was blob it would be storage count one dot blob dot core dot windows dot net when i turn on private link a new zone is created with private link there is now a sa1 in dot private link dot the rest of it and it creates an alias for the regular record that now points to this so the point is i have to have this consistent dns resolution as well when i create a private endpoint it's going to give me a choice to say hey do you want us to manage this for you if you say yes well then this here this zone will get created as an azure private dns zone and it will link it to the network and i could link other networks to it as well what about things that aren't v-net well that's where the other option is rather than using azure dns i could just create a zone called private link dot blob dot cord at windows.net on my dns server which is what i've done in my environment so i use ad and then i add a host record an a record for sa1 that resolves to this ip address it got that's how i do it in my environment but if you really wanted to use azure private dns from on-prem well you would go and create that resolver there we go i drew over here and it would go and forward to azure dns to be able to resolve to it so private endpoint takes the service and gives it an ip address in your virtual network so let's let's look at that so here if i look at this particular there we go okay so here if i look at a particular storage account uh where's my private demo but guess what's in here so if i look at this one i've got a private endpoint for actually both plob and files so if i look at the blob one what we'll actually see is yeah look there's an essay private link demo southcentralyesblog.court at windows.net resolves to ip10.0.1.4 and that's within this particular virtual network we have up here so if i take that name for a second and copy that if i do an ns lookup you'll see hey look the alias is from the regular.blog.cor.windows.net but actually from my dns server this is not azure dns i added a zone for private link.blog.cor.windows.net i added a record for sa prove link demo sus that resolves to the ip address it told me when it got created this doesn't change it's not going to change so to prove this hey i'm on this vm if i go and look at private link demo sus i can get to the content and just to prove something else if i go back to that storage account if i look at the firewall it's only allowed from selected networks and there aren't any so this is completely blocked there's no network or ip address that is allowed to talk to this at all but i'm talking to it because i have a private endpoint if i try and talk to that same storage account from let's go over here let's close it down so if i just refresh out go to blog containers of this private one and try and load it fails it has no permission there's no path even though like i'm a full admin i can get the access key there is no path to that account for me i can only do it via that private endpoint ip now again i could lock this also down with those service endpoints that i talked about before i i still could have done that but in this case i've used that private endpoint the other thing these are actually useful for imagine i had another virtual network that had some service i wanted to use in here now normally i'll just peer them together right what if they got the same ip address range i wasn't paying attention big company they're the same ip range or they overlap in some way i can't hear them so i can use a standard load balancer it has to be standard i can create a private link service link to load balancer and now i can project a private endpoint into this network now things in here can use it it will do network address translation so i don't have to worry about the fact that the ip address ranges overlap it's going to take care of it for me so it's another really useful use for private endpoints it's not just exposing azure services into my virtual network if i have other virtual networks and it's overlapping in some way well i can project it in with a private endpoint and more and more services today actually go ahead and support private endpoints um so here i talk about it does the most efficient path it's instant specific that's why i can only allow in where i've got a private endpoint it removes the need for peering so it's a super powerful thing so we covered a huge amount as always questions please post below but as always please give it a like subscribe comment and share and i'll see you at the next video you

Channel: John Savill's Technical Training

Views: 44,395

Rating: 4.9932942 out of 5

Keywords: azure, azure cloud, azure networking, network security groups, service endpoints, service endpoint policies, private link, private endpoints, networking

Id: K8ePZdLfU7M

Length: 108min 10sec (6490 seconds)

Published: Tue Oct 13 2020