Używanie usługi Private Link w wirtualnej sieci WAN
Usługa Azure Private Link to technologia, która umożliwia łączenie ofert platformy jako usługi platformy Azure przy użyciu łączności prywatnych adresów IP przez uwidacznianie prywatnych punktów końcowych. Usługa Azure Virtual WAN umożliwia wdrożenie prywatnego punktu końcowego w jednej z sieci wirtualnych połączonych z dowolnym koncentratorem wirtualnym. Ten link prywatny zapewnia łączność z dowolną inną siecią wirtualną lub gałęzią połączoną z tą samą usługą Virtual WAN.
Zanim rozpoczniesz
W krokach w tym artykule założono, że wdrożono wirtualną sieć WAN z co najmniej jednym koncentratorem i co najmniej dwie sieciami wirtualnymi połączonymi z usługą Virtual WAN.
Aby utworzyć nową wirtualną sieć WAN i nowe centrum, wykonaj kroki opisane w następujących artykułach:
Zagadnienia dotyczące routingu za pomocą usługi Private Link w usłudze Virtual WAN
Łączność prywatnego punktu końcowego na platformie Azure jest stanowa. Gdy połączenie z prywatnym punktem końcowym zostanie nawiązane za pośrednictwem wirtualnej sieci WAN, ruch jest kierowany przez co najmniej jeden przeskok ruchu przez różne składniki usługi Virtual WAN (na przykład router koncentratora wirtualnego, brama usługi ExpressRoute, bramę VPN Gateway, usługę Azure Firewall lub urządzenie WUS). Dokładny przeskok ruch jest oparty na konfiguracjach routingu usługi Virtual WAN. W tle warstwa sieci zdefiniowana programowo na platformie Azure wysyła wszystkie pakiety związane z jednym przepływem krotki 5-krotkowym do jednego z wystąpień zaplecza obsługujących różne składniki usługi Virtual WAN. Ruch kierowany asymetrycznie (na przykład ruch odpowiadający pojedynczemu przepływowi krotki z 5 krotkami kierowanym do różnych wystąpień zaplecza) nie jest obsługiwany i jest porzucany przez platformę Azure.
Podczas zdarzeń konserwacji w infrastrukturze usługi Virtual WAN wystąpienia zaplecza są ponownie uruchamiane pojedynczo, co może prowadzić do sporadycznych problemów z łącznością z prywatnym punktem końcowym, ponieważ obsługa wystąpienia jest tymczasowo niedostępna. Podobny problem może wystąpić, gdy usługa Azure Firewall lub router koncentratora wirtualnego skaluje się w poziomie. Ten sam przepływ ruchu może być zrównoważony dla nowego wystąpienia zaplecza, które różni się od aktualnie obsługiwanego przepływu.
Aby ograniczyć wpływ zdarzeń konserwacji i skalowania w poziomie w przypadku ruchu usługi Private Link lub prywatnego punktu końcowego, należy wziąć pod uwagę następujące najlepsze rozwiązania:
- Skonfiguruj wartość limitu czasu protokołu TCP dla aplikacji lokalnej, aby mieściła się między 15 a 30 sekundami. Mniejsza wartość limitu czasu protokołu TCP umożliwi szybsze odzyskiwanie ruchu aplikacji po zdarzeniach konserwacji i skalowania w poziomie. Alternatywnie przetestuj różne wartości limitu czasu aplikacji, aby określić odpowiedni limit czasu na podstawie wymagań.
- Wstępnie skalowane składniki usługi Virtual WAN do obsługi wybuchów ruchu, aby zapobiec wystąpieniu zdarzeń autoskalowania. W przypadku routera koncentratora wirtualnego można ustawić minimalną liczbę jednostek infrastruktury routingu na routerze koncentratora, aby zapobiec skalowaniu podczas zwiększania ruchu.
Na koniec, jeśli używasz łączności lokalnej między platformą Azure i środowiskiem lokalnym przy użyciu sieci VPN lub usługi ExpressRoute, upewnij się, że urządzenie lokalne jest skonfigurowane do korzystania z tego samego tunelu VPN lub tego samego routera przeglądarki Microsoft Enterprise Edge co następny przeskok dla każdego 5 krotki odpowiadającego ruchowi prywatnego punktu końcowego.
Tworzenie punktu końcowego łącza prywatnego
Możesz utworzyć punkt końcowy łącza prywatnego dla wielu różnych usług. W tym przykładzie używamy usługi Azure SQL Database. Więcej informacji na temat tworzenia prywatnego punktu końcowego dla usługi Azure SQL Database można znaleźć w przewodniku Szybki start: Tworzenie prywatnego punktu końcowego przy użyciu witryny Azure Portal. Na poniższej ilustracji przedstawiono konfigurację sieci usługi Azure SQL Database:
Po utworzeniu usługi Azure SQL Database możesz zweryfikować prywatny adres IP punktu końcowego przeglądający prywatne punkty końcowe:
Po kliknięciu utworzonego prywatnego punktu końcowego powinien zostać wyświetlony jego prywatny adres IP i w pełni kwalifikowana nazwa domeny (FQDN). Prywatny punkt końcowy powinien mieć adres IP w zakresie sieci wirtualnej (10.1.3.0/24):
Weryfikowanie łączności z tej samej sieci wirtualnej
W tym przykładzie zweryfikujemy łączność z usługą Azure SQL Database z maszyny wirtualnej z systemem Linux za pomocą zainstalowanych narzędzi MS SQL. Pierwszym krokiem jest sprawdzenie, czy rozpoznawanie nazw DNS działa, a w pełni kwalifikowana nazwa domeny usługi Azure SQL Database jest rozpoznawana jako prywatny adres IP w tej samej sieci wirtualnej, w której wdrożono prywatny punkt końcowy (10.1.3.0/24):
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Jak widać w poprzednich danych wyjściowych, nazwa FQDN wantest.database.windows.net jest mapowana na wantest.privatelink.database.windows.net, że prywatna strefa DNS utworzona wzdłuż prywatnego punktu końcowego zostanie rozpoznana jako prywatny adres 10.1.3.228IP . Zaglądanie do prywatnej strefy DNS potwierdzi, że istnieje rekord A dla prywatnego punktu końcowego zamapowanego na prywatny adres IP:
Po zweryfikowaniu prawidłowego rozpoznawania nazw DNS możemy spróbować nawiązać połączenie z bazą danych:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75
Jak widać, używamy specjalnego zapytania SQL, które daje nam źródłowy adres IP widoczny przez serwer SQL od klienta. W takim przypadku serwer widzi klienta z prywatnym adresem IP (10.1.3.75), co oznacza, że ruch przechodzi z sieci wirtualnej bezpośrednio do prywatnego punktu końcowego.
Ustaw zmienne username i password dopasuj poświadczenia zdefiniowane w usłudze Azure SQL Database, aby przykłady w tym przewodniku działały.
Połączenie z innej sieci wirtualnej
Teraz, gdy jedna sieć wirtualna w usłudze Azure Virtual WAN ma łączność z prywatnym punktem końcowym, wszystkie inne sieci wirtualne i gałęzie połączone z usługą Virtual WAN mogą mieć również dostęp do niej. Aby wymienić dwa przykłady, musisz zapewnić łączność za pośrednictwem dowolnego z modeli obsługiwanych przez usługę Azure Virtual WAN, takich jak scenariusz Any-to-any lub scenariusz z siecią wirtualną usług udostępnionych.
Po połączeniu sieci wirtualnej lub gałęzi z siecią wirtualną, w której wdrożono prywatny punkt końcowy, należy skonfigurować rozpoznawanie nazw DNS:
- Jeśli łączysz się z prywatnym punktem końcowym z sieci wirtualnej, możesz użyć tej samej strefy prywatnej, która została utworzona w usłudze Azure SQL Database.
- W przypadku nawiązywania połączenia z prywatnym punktem końcowym z gałęzi (sieć VPN typu lokacja-lokacja, sieć VPN typu punkt-lokacja lub usługa ExpressRoute) należy użyć lokalnego rozpoznawania nazw DNS.
W tym przykładzie nawiązujemy połączenie z innej sieci wirtualnej. Najpierw dołącz prywatną strefę DNS do nowej sieci wirtualnej, aby jej obciążenia mogły rozpoznać w pełni kwalifikowaną nazwę domeny usługi Azure SQL Database do prywatnego adresu IP. Odbywa się to przez połączenie prywatnej strefy DNS z nową siecią wirtualną:
Teraz każda maszyna wirtualna w dołączonej sieci wirtualnej powinna poprawnie rozpoznać nazwę FQDN usługi Azure SQL Database na prywatny adres IP łącza prywatnego:
nslookup wantest.database.windows.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
wantest.database.windows.net canonical name = wantest.privatelink.database.windows.net.
Name: wantest.privatelink.database.windows.net
Address: 10.1.3.228
Aby dokładnie sprawdzić, czy ta sieć wirtualna (10.1.1.0/24) ma łączność z oryginalną siecią wirtualną, w której skonfigurowano prywatny punkt końcowy (10.1.3.0/24), możesz sprawdzić obowiązującą tabelę tras na dowolnej maszynie wirtualnej w sieci wirtualnej:
Jak widać, istnieje trasa wskazująca sieć wirtualną 10.1.3.0/24 wstrzyknięta przez bramy sieci wirtualnej w usłudze Azure Virtual WAN. Teraz możemy wreszcie przetestować łączność z bazą danych:
query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75
W tym przykładzie pokazano, jak utworzyć prywatny punkt końcowy w jednej z sieci wirtualnych dołączonych do wirtualnej sieci WAN zapewnia łączność z resztą sieci wirtualnych i gałęzi w usłudze Virtual WAN.
Następne kroki
Aby uzyskać więcej informacji na temat usługi Virtual WAN, zobacz często zadawane pytania.