Privat slutpunkt, samma servernamn: Azure SQL-anslutningssträngar

Private Link ändrar var en anslutning landar, inte vad anslutningen heter. För Azure SQL Database är den skillnaden hela designen: den logiska servern behåller sitt namn, och den privata slutpunkten tillhandahåller en nätverkspost som namnet matchas till. Att ersätta namnet med en IP-adress är den enda ändringen som bryter TLS, inloggningsuppgifter och verktyg samtidigt. Två anslutningssträngar kan se likvärdiga ut och bete sig helt olika.

Behåll orders-db.database.windows.net och ge klienten ett privat svar för det.

Namnet och adressen har olika uppgifter

Namnet identifierar SQL-tjänsten, och det är vad certifikatet och inloggningen förväntar sig. Den privata adressen tillhandahåller en nätverkspost inne i det anslutna virtuella nätverket. Att blanda ihop det ena med det andra ger en anslutning som når något och inte autentiserar mot något.

Microsofts vägledning för Azure SQL kräver det normala servernamnet från klienter. En direkt IP, och likaså namnet med prefixet privatelink, är inte ett utbytbart inloggningsmål. Verktyg som accepterar en IP accepterar den och misslyckas sedan på TLS eller på autentisering, vilket döljer det egentliga felet. Dessa fel läses som inloggningsproblem tills du tittar på värdnamnet i felet.

Vad den privata zonen faktiskt ändrar

Den privata DNS-zonen registrerar en adress för servern inom namnrymden privatelink, och zonen är länkad till det virtuella nätverk som ska använda den. Matchningen flyttas; anslutningssträngen inte. Formen nedan är en illustration, inte en post att klistra in i en offentlig zon.

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

Underhåll den posten och dess zonlänk som infrastruktur, med en ägare och ett granskningsdatum.

Två zoner med samma ursprung och olika svar är det normala sluttillståndet, inte en konflikt. Offentliga klienter behåller det offentliga svaret, och privata klienter får slutpunktens adress. Felläget att hålla koll på är delvis spridning av den privata vyn, där ett undernät matchas privat och ett annat tyst inte gör det.

Klienter utanför Azure behöver en väg in i den zonen

En VPN-klient sitter utanför Azures matchare, så den privata zonen måste vara nåbar från den hybrida vägen. En Azure DNS-vidarebefordrare eller Azure DNS Private Resolver kan betjäna frågor som kommer via det nätverket. Microsofts vägledning är att vidarebefordra den relevanta offentliga tjänstezonen genom den ordningen i stället för att anta att klienter frågar efter namnet privatelink direkt. Klienter som inte kan matcha det privata svaret faller tyst tillbaka på det offentliga.

Håll vidarebefordrans omfattning medveten, eftersom att ersätta en offentlig zon i bruk bryter namn som ersättningen inte innehåller.

Tillhandahåll i en ordning som håller identiteten fast

Stegen har separata ägare: skapa och godkänn slutpunkten, tillhandahåll VPN-rutten, integrera privat DNS och konfigurera sedan klienten med dess normala servernamn. Att göra DNS före rutten ger tidsgränser som ser ut som DNS-fel. Att göra klienten sist håller en variabel i rörelse i taget. Varje steg har ett observerbart resultat, så inget av dem behöver testas genom att gissa.

En ansluten VPN-ikon väljer inte en privat destination av sig själv.

Vad en privat slutpunkt inte stänger av

Att skapa en privat slutpunkt inaktiverar inte automatiskt offentlig åtkomst till den logiska servern. Det är ett separat driftsättningsbeslut, och det hör hemma efter att de avsedda privata klienterna har bekräftats fungera. Behåll en återställningsväg och ta hänsyn till program som fortfarande använder den offentliga ingången. Att stänga av offentlig åtkomst först är hur en fungerande tjänst blir ett avbrott med ett prydligt granskningsspår.

Kontrollera också vilken anslutningspolicy servern använder.

Redirect skickar klienten till en port på noden efter en inledande gateway-anslutning, vilket ändrar vad klientnätverket måste tillåta. Proxy håller trafiken på gatewayen. En lyckad TCP-handskakning på en port är inte hela inloggningsflödet.

Detta är Azure SQL Database, inte SQL Managed Instance, som har sin egen anslutningsmodell och ingen motsvarande historia med privata slutpunkter. I båda fallen, håll tre saker märkta separat: namnet, nätverksposten och inloggningsuppgiften. Att ändra var en anslutning reser bör aldrig ändra vilken tjänst klienten tror att den talar med.