Prywatny punkt końcowy, ta sama nazwa serwera: parametry połączenia Azure SQL

Private Link zmienia to, gdzie trafia połączenie, a nie to, jak połączenie się nazywa. W przypadku Azure SQL Database ta różnica to cały projekt: serwer logiczny zachowuje swoją nazwę, a prywatny punkt końcowy dostarcza wpis sieciowy, na który nazwa jest rozwiązywana. Zastąpienie nazwy adresem IP to jedyna zmiana, która jednocześnie psuje TLS, poświadczenia i narzędzia. Dwa parametry połączenia mogą wyglądać równoważnie i zachowywać się zupełnie inaczej.

Zachowaj orders-db.database.windows.net i przekaż klientowi prywatną odpowiedź dla niego.

Nazwa i adres mają różne zadania

Nazwa identyfikuje usługę SQL i tego właśnie oczekują certyfikat i logowanie. Prywatny adres dostarcza wpis sieciowy wewnątrz połączonej sieci wirtualnej. Pomylenie jednego z drugim daje połączenie, które do czegoś dociera i względem niczego się nie uwierzytelnia.

Wskazówki Microsoftu dla Azure SQL wymagają od klientów zwykłej nazwy serwera. Bezpośredni adres IP, a także nazwa z prefiksem privatelink, nie są wymiennym celem logowania. Narzędzia, które akceptują adres IP, przyjmą go, a następnie zawiodą na TLS lub na uwierzytelnianiu, co ukrywa prawdziwy błąd. Te błędy czyta się jak problemy z poświadczeniami, dopóki nie spojrzysz na nazwę hosta w komunikacie.

Co faktycznie zmienia strefa prywatna

Prywatna strefa DNS rejestruje jeden adres serwera w przestrzeni nazw privatelink, a strefa jest połączona z siecią wirtualną, która powinna jej używać. Rozwiązywanie się przesuwa; parametry połączenia nie. Poniższy kształt jest ilustracją, a nie rekordem do wklejenia w strefę publiczną.

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

Utrzymuj ten rekord i jego powiązanie ze strefą jako infrastrukturę, z właścicielem i datą przeglądu.

Dwie strefy o tym samym pochodzeniu i różnych odpowiedziach to normalny stan końcowy, a nie konflikt. Klienci publiczni zachowują odpowiedź publiczną, a klienci prywatni otrzymują adres punktu końcowego. Tryb awarii, na który trzeba uważać, to częściowe rozprzestrzenianie widoku prywatnego, gdzie jedna podsieć rozwiązuje się prywatnie, a inna po cichu nie.

Klienci spoza Azure potrzebują ścieżki do tej strefy

Klient VPN znajduje się poza resolverem Azure, więc strefa prywatna musi być osiągalna ze ścieżki hybrydowej. Przekazujący DNS Azure lub Azure DNS Private Resolver mogą obsługiwać zapytania przychodzące przez tę sieć. Wskazówka Microsoftu to przekazywanie odpowiedniej publicznej strefy usługi przez to rozwiązanie, zamiast zakładania, że klienci pytają bezpośrednio o nazwę privatelink. Klienci, którzy nie potrafią rozwiązać prywatnej odpowiedzi, po cichu wracają do publicznej.

Zakres przekazywania utrzymuj świadomie, ponieważ zastąpienie używanej strefy publicznej psuje nazwy, których zamiennik nie zawiera.

Zapewniaj w kolejności, która utrzymuje tożsamość na stałym poziomie

Kroki mają osobnych właścicieli: utwórz i zatwierdź punkt końcowy, zapewnij trasę VPN, zintegruj prywatny DNS, a następnie skonfiguruj klienta z jego zwykłą nazwą serwera. Robienie DNS przed trasą daje przekroczenia czasu, które wyglądają jak awarie DNS. Robienie klienta na końcu utrzymuje w ruchu jedną zmienną naraz. Każdy krok ma obserwowalny wynik, więc żadnego nie trzeba testować przez zgadywanie.

Połączona ikona VPN sama nie wybiera celu prywatnego.

Czego prywatny punkt końcowy nie wyłącza

Utworzenie prywatnego punktu końcowego nie wyłącza automatycznie publicznego dostępu do serwera logicznego. To osobna decyzja wdrożeniowa i należy do niej po potwierdzeniu, że zamierzeni klienci prywatni działają. Zachowaj ścieżkę odzyskiwania i uwzględnij aplikacje, które nadal korzystają z wejścia publicznego. Wyłączenie publicznego dostępu jako pierwszego to sposób, w jaki działająca usługa staje się awarią z porządnym śladem audytu.

Sprawdź także, jakich zasad połączenia używa serwer.

Redirect wysyła klienta do portu na węźle po początkowym połączeniu z bramą, co zmienia to, co musi dopuścić sieć klienta. Proxy utrzymuje ruch na bramie. Udany uścisk dłoni TCP na jednym porcie to nie cały proces logowania.

To jest Azure SQL Database, a nie SQL Managed Instance, która ma własny model łączności i żadnej równoważnej historii prywatnego punktu końcowego. W obu przypadkach trzymaj trzy rzeczy oznakowane osobno: nazwę, wpis sieciowy i poświadczenie. Zmiana tego, dokąd podróżuje połączenie, nigdy nie powinna zmieniać tego, z jaką usługą klient sądzi, że rozmawia.