The concept of Service Endpoints has been around for a while now. Though for today’s post I would like to guide you through the typical process. Here we’ll take a glance of how they work and so that you know what to expect.
For this post we’ll be connecting the Azure PostgreSQL Service to a VNET by leveraging a Service Endpoint. Afterwards we’ll make a connection from a VM within that VNET, and see what route is being taken!
Let’s take a look!
The PostgreSQL service was already provisioned. So let’s head over to “Connection security”. Here you’ll see a section on “VNET rules”, where I already had one rule configured. Though let’s click on “Add existing virtual network” to see what the flow would look like…
A new mini blade will open, and you’ll be presented with the opportunity to create a service endpoint for a specific Subnet.
Once done… The rule is added, like the one you saw before. And that is that… post done! Just kidding… 😉 Initially, my first guess was that the service endpoint would have an internal IP, and that the Azure DNS would intervene in terms of the resolution. Though… if we would take a look at “connected devices” (in the VNET blade), we don’t see anything popping up there.
Same if we go the “Service endpoints” section, we just see service & linked subnets…
Now here I was worried that things were misconfigured. So I went to take a look at “pgAdmin”, and see what IP was seen by the Azure PostgreSQL service… And yes, it’s the private IP. So the service tunneling does work!
Here Thomas gave me a golden pointer to take a look at the effective routs. So let’s head over to the network interface of our virtual machine.
And select “Effective routes” there…
And here we’ll notice that a route was added to our NIC (actually, all NICs linked to the subnet of course) ;
So the technique that is used with Service endpoints is basically done by creating a route that has “VirtualNetworkServiceEndpoint” as the next hop type.
I do hope this post provided some insights into how service endpoints work underneath the hood. My initial speculation (NAT+DNS intercept) was way off… and it’s actually done by inserting a route.