Privé-eindpunt, dezelfde servernaam: Azure SQL-verbindingsreeksen

Private Link verandert waar een verbinding terechtkomt, niet hoe de verbinding heet. Voor Azure SQL Database is dat onderscheid het hele ontwerp: de logische server behoudt zijn naam, en het privé-eindpunt levert een netwerkinvoer waarnaar de naam wordt omgezet. De naam vervangen door een IP-adres is de enige wijziging die TLS, inloggegevens en hulpprogramma's tegelijk breekt. Twee verbindingsreeksen kunnen er gelijk uitzien en zich volstrekt anders gedragen.

Behoud orders-db.database.windows.net en geef de client een privé-antwoord ervoor.

De naam en het adres hebben verschillende taken

De naam identificeert de SQL-service, en dat is wat het certificaat en de aanmelding verwachten. Het privé-adres levert een netwerkinvoer binnen het verbonden virtuele netwerk. Het een met het ander verwarren levert een verbinding op die iets bereikt en zich tegen niets authenticeert.

De richtlijn van Microsoft voor Azure SQL vereist de normale servernaam van clients. Een rechtstreeks IP, en evenzo de naam met het voorvoegsel privatelink, is geen uitwisselbaar aanmelddoel. Hulpprogramma's die een IP accepteren, accepteren het en falen daarna op TLS of op authenticatie, wat de echte fout verbergt. Die fouten lezen als inlogproblemen tot je naar de hostnaam in de fout kijkt.

Wat de privé-zone werkelijk verandert

De privé-DNS-zone registreert één adres voor de server binnen de naamruimte privatelink, en de zone is gekoppeld aan het virtuele netwerk dat deze moet gebruiken. De omzetting verschuift; de verbindingsreeks niet. De vorm hieronder is een illustratie, geen record om in een openbare zone te plakken.

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

Onderhoud dat record en de zonekoppeling als infrastructuur, met een eigenaar en een herzieningsdatum.

Twee zones met dezelfde oorsprong en verschillende antwoorden zijn de normale eindtoestand, geen conflict. Openbare clients behouden het openbare antwoord, en privéclients krijgen het eindpuntadres. De faalmodus om op te letten is gedeeltelijke verspreiding van de privéweergave, waarbij het ene subnet privé wordt omgezet en het andere stilzwijgend niet.

Clients buiten Azure hebben een pad naar die zone nodig

Een VPN-client zit buiten de resolver van Azure, dus moet de privé-zone bereikbaar zijn vanaf het hybride pad. Een Azure DNS-doorstuurprogramma of Azure DNS Private Resolver kan query's bedienen die via dat netwerk binnenkomen. De richtlijn van Microsoft is de betrokken openbare servicezone via die regeling door te sturen in plaats van aan te nemen dat clients de naam privatelink rechtstreeks opvragen. Clients die het privé-antwoord niet kunnen omzetten, vallen stilzwijgend terug op het openbare.

Houd de omvang van het doorsturen bewust, want het vervangen van een openbare zone in gebruik breekt namen die de vervanging niet bevat.

Voorzie in een volgorde die de identiteit vast houdt

De stappen hebben aparte eigenaren: maak en keur het eindpunt goed, lever de VPN-route, integreer privé-DNS en configureer daarna de client met zijn normale servernaam. DNS doen vóór de route levert time-outs op die op DNS-fouten lijken. De client als laatste doen houdt één variabele tegelijk in beweging. Elke stap heeft een waarneembaar resultaat, dus geen enkele hoeft door te raden te worden getest.

Een verbonden VPN-pictogram selecteert niet vanzelf een privé-bestemming.

Wat een privé-eindpunt niet uitschakelt

Het maken van een privé-eindpunt schakelt de openbare toegang tot de logische server niet automatisch uit. Dat is een aparte implementatiebeslissing, en die hoort pas nadat de beoogde privéclients zijn bevestigd als werkend. Behoud een herstelpad en houd rekening met toepassingen die nog de openbare ingang gebruiken. Openbare toegang eerst uitschakelen is hoe een werkende dienst een storing wordt met een nette audittrail.

Controleer ook welk verbindingsbeleid de server gebruikt.

Redirect stuurt de client na een eerste gateway-verbinding naar een poort op het knooppunt, wat verandert wat het clientnetwerk moet toestaan. Proxy houdt het verkeer op de gateway. Een geslaagde TCP-handdruk op één poort is niet de hele aanmeldingsworkflow.

Dit is Azure SQL Database, niet SQL Managed Instance, die een eigen connectiviteitsmodel heeft en geen vergelijkbaar verhaal over privé-eindpunten. Houd in beide gevallen drie dingen apart gelabeld: de naam, de netwerkinvoer en de inloggegevens. Wijzigen waar een verbinding reist, mag nooit wijzigen met welke service de client denkt te praten.