Ponto de extremidade privado, mesmo nome de servidor: cadeias de conexão do Azure SQL

O Private Link muda onde uma conexão chega, não como a conexão se chama. Para o Azure SQL Database, essa distinção é todo o desenho: o servidor lógico mantém o seu nome, e o ponto de extremidade privado fornece uma entrada de rede para a qual o nome é resolvido. Substituir o nome por um endereço IP é a única alteração que quebra TLS, credenciais e ferramentas ao mesmo tempo. Duas cadeias de conexão podem parecer equivalentes e comportar-se de forma completamente diferente.

Mantenha orders-db.database.windows.net e dê ao cliente uma resposta privada para ele.

O nome e o endereço têm funções diferentes

O nome identifica o serviço SQL, e é isso que o certificado e o início de sessão esperam. O endereço privado fornece uma entrada de rede dentro da rede virtual conectada. Confundir um com o outro produz uma conexão que chega a algo e não se autentica contra nada.

A orientação da Microsoft para o Azure SQL exige o nome de servidor normal dos clientes. Um IP direto, e igualmente o nome com o prefixo privatelink, não é um alvo de início de sessão intercambiável. As ferramentas que aceitam um IP aceitam-no e depois falham em TLS ou na autenticação, o que esconde o erro real. Essas falhas leem-se como problemas de credenciais até se olhar para o nome de host no erro.

O que a zona privada realmente muda

A zona DNS privada regista um endereço para o servidor dentro do espaço de nomes privatelink, e a zona está ligada à rede virtual que a deve usar. A resolução desloca-se; a cadeia de conexão não. A forma abaixo é uma ilustração, não um registo para colar numa zona pública.

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

Mantenha esse registo e a sua ligação de zona como infraestrutura, com um responsável e uma data de revisão.

Duas zonas com a mesma origem e respostas diferentes são o estado final normal, não um conflito. Os clientes públicos mantêm a resposta pública, e os clientes privados recebem o endereço do ponto de extremidade. O modo de falha a vigiar é a propagação parcial da vista privada, em que uma sub-rede se resolve de forma privada e outra, em silêncio, não.

Os clientes fora do Azure precisam de um caminho para essa zona

Um cliente VPN fica fora do resolvedor do Azure, por isso a zona privada tem de ser alcançável a partir do caminho híbrido. Um reencaminhador DNS do Azure ou o Azure DNS Private Resolver podem servir as consultas que chegam por essa rede. A orientação da Microsoft é reencaminhar a zona de serviço público relevante através dessa disposição, em vez de assumir que os clientes consultam diretamente o nome privatelink. Os clientes que não conseguem resolver a resposta privada voltam à pública sem se queixarem.

Mantenha o âmbito do reencaminhamento intencional, porque substituir uma zona pública em uso quebra nomes que a substituição não contém.

Aprovisione numa ordem que mantenha a identidade fixa

Os passos têm responsáveis separados: crie e aprove o ponto de extremidade, forneça a rota VPN, integre o DNS privado e, em seguida, configure o cliente com o seu nome de servidor normal. Fazer o DNS antes da rota produz tempos limite que parecem falhas de DNS. Fazer o cliente por último mantém uma variável em movimento de cada vez. Cada passo tem um resultado observável, pelo que nenhum tem de ser testado por adivinhação.

Um ícone de VPN ligado não seleciona um destino privado por si só.

O que um ponto de extremidade privado não desliga

Criar um ponto de extremidade privado não desativa automaticamente o acesso público ao servidor lógico. Essa é uma decisão de implementação separada, e pertence depois de os clientes privados previstos estarem confirmados como funcionais. Mantenha um caminho de recuperação e considere as aplicações que ainda usam a entrada pública. Desativar primeiro o acesso público é como um serviço a funcionar se transforma numa interrupção com um registo de auditoria arrumado.

Verifique também que política de ligação o servidor usa.

O Redirect envia o cliente para uma porta no nó após uma ligação inicial ao gateway, o que altera o que a rede do cliente tem de permitir. O Proxy mantém o tráfego no gateway. Um aperto de mão TCP bem-sucedido numa porta não é todo o fluxo de início de sessão.

Isto é Azure SQL Database, não SQL Managed Instance, que tem o seu próprio modelo de conectividade e nenhuma história equivalente de ponto de extremidade privado. Em ambos os casos, mantenha três coisas rotuladas em separado: o nome, a entrada de rede e a credencial. Mudar por onde viaja uma conexão nunca deve mudar com que serviço o cliente pensa que está a falar.