You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-wan/howto-private-link.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ ms.custom: fasttrack-new
18
18
19
19
## Before you begin
20
20
21
-
The steps in this article assume that you have already deployed a virtual WAN with one or more hubs and at least two virtual networks connected to Virtual WAN.
21
+
The steps in this article assume that you've already deployed a virtual WAN with one or more hubs and at least two virtual networks connected to Virtual WAN.
22
22
23
23
To create a new virtual WAN and a new hub, use the steps in the following articles:
24
24
@@ -28,15 +28,15 @@ To create a new virtual WAN and a new hub, use the steps in the following articl
28
28
29
29
## <aname="endpoint"></a>Create a private link endpoint
30
30
31
-
You can create a private link endpoint for many different services. In this example, we are using Azure SQL Database. You can find more information about how to create a private endpoint for an Azure SQL Database in [Quickstart: Create a Private Endpoint using the Azure portal](../private-link/create-private-endpoint-portal.md). The following image shows the network configuration of the Azure SQL Database:
31
+
You can create a private link endpoint for many different services. In this example, we're using Azure SQL Database. You can find more information about how to create a private endpoint for an Azure SQL Database in [Quickstart: Create a Private Endpoint using the Azure portal](../private-link/create-private-endpoint-portal.md). The following image shows the network configuration of the Azure SQL Database:
Clicking on the private endpoint we have created, you should see its private IP address and its Fully Qualified Domain Name (FQDN). The private endpoint should have an IP address in the range of the VNet where it has been deployed (10.1.3.0/24):
39
+
Clicking on the private endpoint we've created, you should see its private IP address and its Fully Qualified Domain Name (FQDN). The private endpoint should have an IP address in the range of the VNet where it has been deployed (10.1.3.0/24):
As you can see in the previous output, the FQDN `wantest.database.windows.net` is mapped to `wantest.privatelink.database.windows.net`, that the private DNS zone created along the private endpoint will resolve to the private IP address `10.1.3.228`. Looking into the private DNS zone will confirm that there is an A record for the private endpoint mapped to the private IP address:
61
+
As you can see in the previous output, the FQDN `wantest.database.windows.net` is mapped to `wantest.privatelink.database.windows.net`, that the private DNS zone created along the private endpoint will resolve to the private IP address `10.1.3.228`. Looking into the private DNS zone will confirm that there's an A record for the private endpoint mapped to the private IP address:
As you can see, we are using a special SQL query that gives us the source IP address that the SQL server sees from the client. In this case the server sees the client with its private IP (`10.1.3.75`), which means that the traffic goes from the VNet straight into the private endpoint.
76
+
As you can see, we're using a special SQL query that gives us the source IP address that the SQL server sees from the client. In this case the server sees the client with its private IP (`10.1.3.75`), which means that the traffic goes from the VNet straight into the private endpoint.
77
77
78
78
Set the variables `username` and `password` to match the credentials defined in the Azure SQL Database to make the examples in this guide work.
79
79
@@ -86,7 +86,7 @@ Once you have connectivity between the VNet or the branch to the VNet where the
86
86
* If connecting to the private endpoint from a VNet, you can use the same private zone that was created with the Azure SQL Database.
87
87
* If connecting to the private endpoint from a branch (Site-to-site VPN, Point-to-site VPN or ExpressRoute), you need to use on-premises DNS resolution.
88
88
89
-
In this example we are connecting from a different VNet. First attach the private DNS zone to the new VNet so that its workloads can resolve the Azure SQL Database Fully Qualified Domain Name to the private IP address. This is done through linking the private DNS zone to the new VNet:
89
+
In this example we're connecting from a different VNet. First attach the private DNS zone to the new VNet so that its workloads can resolve the Azure SQL Database Fully Qualified Domain Name to the private IP address. This is done through linking the private DNS zone to the new VNet:
As you can see, there is a route pointing to the VNet 10.1.3.0/24 injected by the Virtual Network Gateways in Azure Virtual WAN. Now we can finally test connectivity to the database:
113
+
As you can see, there's a route pointing to the VNet 10.1.3.0/24 injected by the Virtual Network Gateways in Azure Virtual WAN. Now we can finally test connectivity to the database:
With this example, we have seen how creating a private endpoint in one of the VNets attached to a Virtual WAN provides connectivity to the rest of VNets and branches in the Virtual WAN.
124
+
With this example, we've seen how creating a private endpoint in one of the VNets attached to a Virtual WAN provides connectivity to the rest of VNets and branches in the Virtual WAN.
0 commit comments