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