/ /

Endpoints privados

Página inicial do Docs

Desenvolvimento

Conectar-se a um cluster

Endpoints privados

Página inicial do Docs

Desenvolvimento

Conectar-se a um cluster

Endpoints privados

Solução de problemas de conexão de endpoints privados

Os endpoints privados do GCP não mapeados de porta estão obsoletos e serão desativados em 30 de abril de 2027. Após essa data, você não poderá criar novos pontos de extremidade não mapeados de porta e os pontos de extremidade existentes deixarão de funcionar. Crie novos serviços de ponto de extremidade GCP que usam arquitetura de mapeamento de portas para reduzir o uso de IP e melhorar a escalabilidade. Para saber como converter pontos de extremidade legados para mapeamento de portas, consulte Convertendo pontos de extremidade privados legados para usar a arquitetura de mapeamento de portas.

Observação

Esta página se aplica tanto ao Atlas Infinite quanto ao Atlas Core.

Revise as seções desta página para diagnosticar e resolver problemas comuns de conexão de private endpoints.

Clusters dedicados

Verifique o status de suas conexões do AWS PrivateLink.

Para visualizar o status de cada endpoint privado:

No Atlas, acesse a página Database & Network Access do seu projeto.
1. Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
2. Se ainda não estiver exibido, selecione seu projeto no menu Projects na barra de navegação.
3. Na barra lateral, clique em Database & Network Access sob o título Security.
  The Database & Network Access page displays.
Na barra lateral, clique em Private Endpoint.
Revise os status.
Os campos Atlas Endpoint Service Status e Endpoint Status mostram o status de cada endpoint privado.

Consulte os status a seguir para ajudá-lo a determinar o estado de suas conexões de endpoint privado:

Atlas Endpoint Service Status

Status	Descrição
Criando link privado	O Atlas está criando o balanceador de carga de rede e os recursos de VPC .
Falhou	Ocorreu uma falha no sistema.
Disponível	O balanceador de carga de rede do Atlas e o serviço de endpoints da VPC estão criados e prontos para receber solicitações de conexão.
Excluindo	O Atlas está excluindo o serviço de endpoint privado.

Endpoint Status

Status

Descrição

Não configurado

Atlas created the network load balancer and VPC endpoint service, but AWS hasn't yet created the interface endpoint. Click Edit and complete the wizard to create the interface endpoint.

Aceitação pendente

AWS has received the connection request from your interface endpoint to the Atlas VPC endpoint service.

Pendente

O Amazon Web Services está estabelecendo a conexão entre o ponto de extremidade da interface e o serviço de endpoint do Atlas VPC.

Falhou/rejeitado

AWS failed to establish a connection between Atlas VPC resources and the interface endpoint in your VPC. This status may appear as Failed or Rejected depending on the failure reason.

As causas comuns incluem:

Região ausente na lista de regiões de ponto de extremidade aceitas
ID de ponto de extremidade VPC incorreta
Problemas transitórios da AWS

Se você confirmou que sua configuração está correta e a falha pode ser devido a atrasos temporários da AWS, você pode usar o botão Retry na IU do Atlas para tentar novamente a conexão. Se o problema persistir, clique em Edit para corrigir o ID do ponto de extremidade ou verifique se a região do ponto de extremidade está incluída nas regiões de ponto de extremidade aceitas.

To learn more about troubleshooting failed endpoints, see Troubleshoot Private Endpoint Connection Issues.

IMPORTANTE: se o ponto de conexão da interface falhar, você poderá ver a seguinte mensagem:

No dns entries found for endpoint vpce-<guid>,
your endpoint must be provisioned in at least one subnet.
Click "Edit" to fix the problem.

Esta mensagem indica que você não especificou uma sub-rede ao criar a conexão do AWS PrivateLink. Para resolver esse erro:

Clique em Edit.
Clique em Back.
Especifique pelo menos uma sub-rede.
Siga as instruções restantes para criar a conexão do AWS PrivateLink.

Disponível

Atlas VPC resources are connected to the interface endpoint in your VPC. You can connect to Atlas clusters in this region using AWS PrivateLink.

Excluindo

O Atlas está removendo o ponto de conexão da ponto de extremidade da interface do serviço de endpoint privado.

Certifique-se de que seus grupos de segurança estejam configurados corretamente.

For each resource that needs to connect to your Atlas clusters using AWS PrivateLink, the resource's security group must allow outbound traffic to the interface endpoint's private IP addresses on all ports (1024-65535).
Consulte Adicionar regras a um grupo de segurança para maiores informações.
O grupo de segurança do ponto de extremidade da interface deve permitir o tráfego de entrada em todas as portas de cada recurso que precisa se conectar aos Atlas clusters usando o AWS PrivateLink.
Acesse endereços IP da instância ou grupos de segurança para permitir que o tráfego deles alcance o grupo de segurança do ponto de extremidade da interface.

Problemas de pontos de extremidade privados entre regiões

As seções a seguir descrevem problemas comuns de conectividade de pontos de extremidade privados entre regiões e como resolvê-los.

Falha no envio do ponto de extremidade (região ausente)

Se você se esqueceu de especificar a região em que o ponto de extremidade do consumidor está localizado durante o envio, o status do ponto de extremidade no Atlas transita para Failed ou Rejected, pois o serviço de ponto de extremidade não pode localizar e aceitar a conexão.

Para resolver esse problema:

Adicione a região ausente às regiões de ponto de extremidade aceitas.

Adicione a região ausente à lista de regiões de ponto de extremidade aceitas. Para saber mais, consulte Gerenciar regiões de ponto de extremidade aceitas.

Tente novamente a conexão.

Depois de adicionar a região, retorne ao cartão de serviço do ponto de extremidade e clique no botão Retry ao lado da entrada do ponto de extremidade com falha.

Aviso

Não exclua um ponto de extremidade com falha se ele for o único ponto de extremidade registrado nesse serviço de ponto de extremidade privado. Se você excluir o último ponto de extremidade, todo o serviço de ponto de extremidade será excluído automaticamente e você deverá reiniciar todo o processo de configuração.

Falha no envio do ponto de extremidade (ID de ponto de extremidade incorreto)

Se você enviar um ID de ponto de extremidade VPC da AWS incorreto (por exemplo, um erro de digitação ou um ID de um serviço ou VPC diferente), o status do ponto de extremidade no Atlas muda para Failed ou Rejected porque o serviço de ponto de extremidade não consegue localizar e aceitar a conexão.

Você pode resolver este problema usando um dos seguintes métodos.

Para corrigir o ID na entrada do ponto de extremidade existente:

Localize o ponto de extremidade com falha.

No cartão de serviço do ponto de extremidade, localize a entrada do ponto de extremidade com falha.

Edite o ID do ponto de extremidade.

Clique no botão Edit na coluna Actions.
No modal, atualize o campo VPC Endpoint ID com o ID correto.
Clique em Save para atualizar o ID.
O Atlas tenta aceitar o ponto de extremidade correto.

Para substituir a entrada com falha por um novo ponto de extremidade em vez disso:

Adicione um novo ponto de extremidade com o ID correto.

Adicione um novo ponto de extremidade usando o ID de ponto de extremidade correto. Para saber mais, consulte Configurar um ponto de extremidade privado para um cluster dedicado.

Exclua o ponto de extremidade com falha.

Depois que o ponto de extremidade correto for aceito com sucesso (o status é exibido como Available), você poderá excluir a entrada do ponto de extremidade com falha.

Aviso

Falha no envio do ponto de extremidade (erro transitório ou desconhecido)

Se o envio de um ponto de extremidade falhar e você já tiver verificado que:

A região necessária está incluída nas regiões de ponto de extremidade aceitas para o serviço de pontos de extremidade privados.
O ID do ponto de extremidade enviado está correto e corresponde ao ponto de extremidade da VPC que você criou na Amazon Web Services.

A falha pode ser devido a um problema transitório da AWS ou um erro no processo de aceitação inicial.

Observação

Mesmo depois que o ponto de extremidade estiver no estado Pending Acceptance no AWS, pode haver um pequeno atraso para que todos os recursos de segundo plano sejam atualizados. Pontos de extremidade entre regiões, em particular, podem levar 30 segundos adicionais para se tornarem detectáveis pelo serviço de ponto de extremidade do Atlas em uma região diferente.

Para resolver esse problema:

Localize o ponto de extremidade com falha.

No cartão de serviço do ponto de extremidade, localize a entrada do ponto de extremidade com falha (o status é exibido como Failed ou Rejected).

Tente novamente a conexão.

Clique no botão Retry na coluna Actions para tentar estabelecer a conexão novamente.

Aviso

Obtenha IPs privados com pesquisa de DNS

When a client in your VPC connects to an Atlas cluster using one of these private endpoint-aware connection strings, the client attempts to establish a connection to the load balancer in the Atlas VPC through one of the interface endpoints. Your client's DNS resolution mechanism handles which of the interface endpoints the hostname resolves to. If one interface endpoint is unavailable the next is used. This is opaque to the driver or other connection mechanism. The driver is only aware of the hostname in the SRV record or in the connection string.

Registro SRV para connection strings com reconhecimento de endpoints privados de lista de sementes de DNS

O exemplo a seguir mostra o registro SRV de um cluster de região única habilitado para o AWS PrivateLink, mostrando três portas exclusivas definidas para pl-0-us-east-1.k45tj.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

No exemplo anterior:

_mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net é o registro SRV ao qual a string de conexão mongodb+srv://cluster0-pl-0.k45tj.mongodb.net faz referência.
pl-0-us-east-1.k45tj.mongodb.net é o nome de host para cada nó em um cluster do Atlas em uma região para a qual você configurou o AWS PrivateLink.
1024, 1025 e 1026 são portas exclusivas que o Atlas atribui ao balanceador de carga para cada nó do conjunto de réplicas do Atlas na região para a qual você habilitou o AWS PrivateLink. balanceador de carga resolvendo nós individuais por sua porta exclusiva.

Resolução de DNS para nomes de host em connection strings e registros SRV com suporte a endpoints privados

The hostname in the SRV record and the standard connection string is a DNS Canonical Name (CNAME) record that resolves to the endpoint-specific regional DNS name that AWS generates for the interface endpoint. A DNS ALIAS record exists for each subnet in your VPC that you deployed the interface endpoint to. Each ALIAS record contains the private IP address of the interface endpoint for that subnet.

O exemplo a seguir mostra a pesquisa de DNS para o nome de host no registro SRV e na connection string padrão, incluindo o nome DNS regional específico do ponto de extremidade para o ponto de extremidade da interface e seus registros de DNS ALIAS:

$ nslookup pl-0-us-east-1.k45tj.mongodb.net
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
pl-0-us-east-1.k45tj.mongodb.net
canonical name = vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com.
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.30.194
Name: vpce-024f5b57108c8d3ed-ypwbxwll.vpce-svc-02863655456245e5c.us-east-1.vpce.amazonaws.com
Address: 10.0.20.54

Conexão recusada porque há muitas conexões abertas

If your connections exceed the connection limits for your cluster service limit, you should increase the cluster tier.
If your connection count is significantly higher than your expected connection count, see section below Gather More Information on the Client Making the Most Connections.
Por exemplo, aplicação em um cluster fragmentado v7.0.22 usando string de conexão otimizada com balanceamento de carga.

$ mongosh "mongodb+srv://aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/" --apiVersion 1 --username sarah
  Enter password: *****
  Current Mongosh Log ID:    68910f1754be6d9adc74e399
  Connecting to:             mongodb+srv://<credentials>@aws-replica-set-7-pl-0-lb.22qdu.mongodb-dev.net/?appName=mongosh+2.5.6
  MongoNetworkError: Client network socket disconnected before secure TLS connection was established

{"t":{"$date":"2025-08-04T19:48:17.649+00:00"},"s":"I", "c":"NETWORK",
"id":22942, "ctx":"listener","msg":"Connection refused because there are
too many open connections","attr":{"remote":"54.172.143.8:33205",
"isLoadBalanced":false,"uuid":{"uuid":{"$uuid":"e52e9c14-7648-430a-bc2e-95292347b7e0"}},
"connectionId":380,"connectionCount":58}}

Como visualizar o IP de origem do cliente

Você pode visualizar o IP de origem do cliente nos logs mongos para clusters fragmentados que se conectam por meio de Endpoints privados.
Você pode visualizar o IP de origem do cliente nos registros do mongod para conjuntos de réplicas que se conectam por meio de endpoints privados.
Você pode visualizar o IP de origem do cliente nos logs de auditar para conjuntos de réplicas e clusters fragmentados que se conectam por meio de Endpoints Privados.
Essa funcionalidade é compatível com o Amazon Web Services para as seguintes versões:
- 8.1 e v8.1.0+
- 8.0 e v8.0.10+
- 7.0 e v7.0.22+

O endereço IP e a porta do cliente de origem são indicados pelo campo sourceClient. Esse valor é 10.50.4.23 no exemplo acima.

{"t":{"$date":"2025-07-21T12:15:42.123+00:00"},"s":"I","c":"NETWORK",
"id":22943,"ctx":"listener","msg":"Connection accepted","attr":{"remote":"192.168.100.55:31245",
"isLoadBalanced":true,"sourceClient":"10.50.4.23:50123","uuid":{"uuid":{"$uuid":"12345678-abcd-4321-abcd-87654321abcd"}},
"connectionId":345,"connectionCount":19}}

Reúna mais informações sobre o cliente que faz a maioria das conexões

A coleta desses detalhes requer o uso da ferramenta jq, que pode ser baixada do site da jq.

Conexões criadas a partir dos metadados do cliente

A query a seguir fornece o número de conexões criadas a partir do endereço IP de um cliente específico. Você pode coletar o endereço IP privado VPC de origem exata usando o atributo sourceClient.

grep 'Connection accepted' mongod.log | jq -r '(.attr.sourceClient // .attr.remote)' | awk -F: '{print $1}' | sort | uniq -c | sort -rn

25957 192.168.254.155
25957 192.168.253.161
25957 192.168.248.236
14420 10.70.2.254
14420 10.70.2.116

Drivers usados pelos aplicativos para se conectar ao cluster

A query a seguir fornece o número de conexões criadas por cada driver. Isso é útil em cenários em que os clientes podem usar drivers diferentes para aplicativos diferentes.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.driver.name' | grep -v null | sort | uniq -c | sort -rn

56447    mongo-go-driver
21633    mongo-java-driver|sync
   75    mongo-java-driver|sync|Airbyte
    4    nodejs|Mongoose

Para obter uma análise mais detalhada das contagens de conexões e detalhes do driver, você pode usar o seguinte script do Python, que fornece informações abrangentes sobre o número de conexões criadas e encerradas, juntamente com os nomes do driver e detalhes da versão.

import json
import sys
def process_log_file(json_file_path):
    # Dictionary to store the filtered data
    filtered_data = {}
    with open(json_file_path, "r") as json_file:
        # Read the file line by line
        for line in json_file:
            # Parse each line as a separate JSON object
            data = json.loads(line)
            if 'msg' in data and data['msg'] == 'client metadata':
                # Extract the relevant data from the JSON object
                drivername = data['attr']['doc']['driver']['name']
                driverversion = data['attr']['doc']['driver']['version']
                connectionid = data['ctx']
                # Create a unique key for the driver based on name and version
                driver_key = (drivername, driverversion)
                # Add the connection ID to the driver's set of connections
                if driver_key not in filtered_data:
                    filtered_data[driver_key] = {'connections': set(), 'opencount': 0, 'closedcount': 0}
                filtered_data[driver_key]['connections'].add(connectionid)
                filtered_data[driver_key]['opencount'] += 1
            if 'msg' in data and data['msg'] == 'Connection ended':
                connectionid = data['ctx']
                # Check if the connection ID exists in any driver's connections
                for driver_data in filtered_data.values():
                    if connectionid in driver_data['connections']:
                        driver_data['closedcount'] += 1
                        driver_data['connections'].remove(connectionid)
    # Print the filtered data for each driver
    for driver_key, driver_data in filtered_data.items():
        print('Driver:', driver_key)
        print('Connection Opened:', driver_data['opencount'])
        print('Connection Closed:', driver_data['closedcount'])
if __name__ == '__main__':
    # Check if a JSON file argument is provided
    if len(sys.argv) < 2:
        print("Please provide the path to a JSON file as an argument.")
        sys.exit(1)
    # Extract the JSON file path from the command-line arguments
    json_file_path = sys.argv[1]
    # Process the log file
    process_log_file(json_file_path)

Driver: ('mongo-go-driver', 'v1.12.0-cloud')
Connection Opened: 14368
Connection Closed: 14362
Driver: ('mongo-go-driver', 'v1.12.1')
Connection Opened: 42056
Connection Closed: 41958
Driver: ('mongo-java-driver|sync', '4.11.1')
Connection Opened: 18012
Connection Closed: 17987
Driver: ('mongo-java-driver|sync', '4.8.2')
Connection Opened: 3621
Connection Closed: 3610
Driver: ('nodejs|Mongoose', '4.17.1|6.12.0')
Connection Opened: 3
Connection Closed: 1
Driver: ('mongo-go-driver', 'v1.13.0')
Connection Opened: 23
Connection Closed: 20
Driver: ('mongo-java-driver|sync|Airbyte', '4.11.0')
Connection Opened: 75
Connection Closed: 75
Driver: ('nodejs|Mongoose', '4.17.2|6.13.0')
Connection Opened: 1
Connection Closed: 0

Nomes de aplicativos usados por aplicativos do cliente para se conectar ao cluster

We can suggest that customers include the application name in the connection string to specify different applications connecting to the cluster. By using the appName, we can identify which application is creating many connections to the cluster in the future. See the Miscellaneous Configuration section of our documentation for more details on using the appName in the connection string. Additionally, you can use the db.currentOp().appname command to see the current operations associated with the application name. The following query provides details of the appName with the number of connections created by that particular application.

more mongodb.log| grep 'NETWORK' | jq -r '.attr.doc.application.name' | grep -v null | sort | uniq -c | sort -rn

10809   niyo-*******-api
8616    MongoDB CPS Module v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
7203    niyo-ns*****
5752    MongoDB Automation Agent v13.17.2.8878 (git: 70c0b932f47f4f0b3e82a75e223f39ed9635b47f)
3601    *****-auth-service

Os detalhes fornecidos ajudam a identificar os fatores específicos que contribuem para o grande número de conexões. Ao analisar o IP do cliente de origem, os metadados do cliente , o uso do driver e os nomes do aplicação , você pode identificar quais elementos são responsáveis pelo aumento das conexões e determinar as áreas necessárias a serem investigadas. Essa abordagem direcionada permite que você desconsidere outros fatores menos relevantes e se concentre na resolução dos problemas com as informações destacadas, simplificando o processo de mitigação e melhorando o desempenho do cluster.

Endpoints privados de várias regiões

Os endpoints privados só estarão disponíveis em clusters multirregional se houver um nó em cada região abrangeda pelo cluster que tenha um endpoint privado configurado. Para saber mais sobre como configurar endpoints privados de multirregional , consulte Endpoints privados regionalizados para clusters fragmentados de várias regiões.

Indexação de connection string para clusters multirregionais

Depois de configurar um endpoint privado para uma nova região e distribuir nós de cluster nessa região, você poderá ver o seguinte erro ao usar seu endpoint privado para se conectar ao cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

Esse erro ocorre quando o índice da connection string muda automaticamente e o cliente é reiniciado posteriormente, o que causa uma pesquisa de DNS SRV. A string de conexão de endpoint privado para um cluster multirregional usa um índice de 0. Se sua string de conexão usar um índice diferente, o MongoDB atualizará automaticamente a string de conexão para usar o índice 0.

Por exemplo, você pode configurar dois endpoints privados para uma região. Se você remover o primeiro endpoint privado, sua string de conexão usará um índice de 1 e será semelhante à seguinte:

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

Em seguida, suponha que você configure um endpoint privado para uma nova região em seu cluster e, posteriormente, adicione nós de cluster a essa região. Seu cluster agora inclui várias regiões e sua string de conexão é atualizada para usar um índice de 0:

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Para evitar possíveis problemas de conectividade após a próxima reinicialização do cliente, confirme que você está usando a string de conexão de ponto de extremidade privado indexado a zero para se conectar ao cluster. Você poderá acessar a string de conexão atualizada do endpoint privado a partir da UI ou da API do Atlas após a conclusão das alterações de cluster.

Teste a conectividade do seu aplicativo implantado

Você pode usar as ferramentas nslookup e telnet para testar a conectividade do seu aplicação com o Endpoint Privado no Atlas.

Obtenha os detalhes da conexão do seu Atlas cluster.

Execute nslookup com o sinalizador -type=SRV para obter os números de porta associados a cada um dos nós em seu cluster.

 nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net

 Server: 127.0.0.53
 Address: 127.0.0.53#53
 Non-authoritative answer:
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

Teste a conectividade.

Em seu ambiente de aplicação , com uma das portas listadas (por exemplo, 1026, 1024 ou 1025 no exemplo de saída acima), execute o seguinte comando telnet para testar a conectividade:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

Para visualizar o status de cada endpoint privado:

No Atlas, vá para a página Database & Network Access do seu projeto.

Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione seu projeto no menu Projects na barra de navegação.
Na barra lateral, clique em Database & Network Access sob o título Security.

The Database & Network Access page displays.

Na barra lateral, clique em Private Endpoint.

Revise os status.

Os campos Atlas Endpoint Service Status e Endpoint Status mostram o status de cada endpoint privado.

Consulte os status a seguir para ajudá-lo a determinar o estado de suas conexões de endpoint privado:

Atlas Endpoint Service Status

Status	Descrição
Criando link privado	O Atlas está criando o balanceador de carga e os recursos de rede virtual.
Falhou	Ocorreu uma falha no sistema.
Disponível	Atlas criou o balanceador de carga e o Azure Private Link Service. O serviço Azure Private Link está pronto para receber solicitações de conexão.
Excluindo	O Atlas está excluindo o serviço Azure Private Link .

Endpoint Status

Status	Descrição
Não configurado	O Atlas criou o balanceador de carga e o Serviço Azure Private Link , mas você ainda não criou um endpoint privado. Clique em Edit e conclua o assistente para criar o endpoint privado.
Iniciando	O Atlas ainda não aceitou a conexão com seu endpoint privado.
Falhou	Azure falhou ao estabelecer uma conexão entre os recursos da VNet do Atlas e o private endpoint na sua VNet. Clique em Edit, verifique se as informações fornecidas estão corretas e, em seguida, crie o ponto de extremidade privado novamente.
Disponível	Os recursos Atlas VNet são conectados ao endpoint privado em sua VNet. Você pode se conectar a clusters do Atlas nessa região usando o Azure Private Link.
Excluindo	O Atlas está removendo a conexão de endpoint privado do Serviço Azure Private Link .

Aviso

Obtenha IPs privados com pesquisa de DNS

Quando um cliente em sua VNet se conecta a um cluster do Atlas usando uma dessas strings de conexão com reconhecimento de private endpoint, o cliente tenta estabelecer uma conexão com o serviço Private Link na VNet do Atlas por meio da interface de rede do private endpoint. O serviço Private Link envia tráfego por meio de um balanceador de carga padrão do Azure para os nós do cluster do Atlas que você implantou nessa região. O mecanismo de resolução de DNS do seu cliente trata da resolução do nome do host para o endereço IP privado da interface de rede. O driver conhece apenas o nome do host na string de conexão, escutando em uma porta para cada nó no conjunto de réplicas do cluster.

Registro SRV para connection strings com reconhecimento de endpoints privados de lista de sementes de DNS

O exemplo a seguir mostra o registro SRV de um cluster de região única habilitado para o Azure Private Link, mostrando três portas exclusivas definidas para pl-0-eastus2.uzgh6.mongodb.net:

$ nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net
Server:  127.0.0.53
Address:  127.0.0.53#53
Non-authoritative answer:
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1024 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1025 pl-0-eastus2.uzgh6.mongodb.net.
_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net service = 0 0 1026 pl-0-eastus2.uzgh6.mongodb.net.

No exemplo anterior:

_mongodb._tcp.cluster0-pl-0.uzgh6.mongodb.net é o registro SRV que a string de conexão referencia.
pl-0-eastus2.uzgh6.mongodb.net é o nome de host para cada nó em um Atlas cluster em uma região para a qual você configurou o Azure Private Link.
1024, 1025 e 1026 são portas exclusivas que o Atlas atribui ao balanceador de carga para cada nó do conjunto de réplicas do Atlas na região para a qual você habilitou o Azure Private Link. Todos os nós em um conjunto de réplicas do Atlas são acessíveis por meio do mesmo nome de host, com o balanceador de carga resolvendo nós individuais por sua porta exclusiva.

Resolução de DNS para nomes de host em connection strings e registros SRV com suporte a endpoints privados

O nome do host no registro SRV e a string de conexão padrão são um registro DNS A que é resolvido para o endereço IP privado da interface de rede do ponto de extremidade privado.

O exemplo a seguir mostra a pesquisa DNS para o nome do host no registro SRV e na string de conexão padrão:

$ nslookup pl-0-eastus2.uzgh6.mongodb.net
Server:  127.0.0.53
Address:  127.0.0.53#53
Non-authoritative answer:
Name:  pl-0-eastus2.uzgh6.mongodb.net
Address: 10.0.0.4

Endpoints privados de várias regiões

Indexação de connection string para clusters multirregionais

Depois de configurar um endpoint privado para uma nova região e distribuir nós de cluster nessa região, você poderá ver o seguinte erro ao usar seu endpoint privado para se conectar ao cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Teste a conectividade do seu aplicativo implantado

Você pode usar as ferramentas nslookup e telnet para testar a conectividade do seu aplicação com o Endpoint Privado no Atlas.

Obtenha os detalhes da conexão do seu Atlas cluster.

Execute nslookup com o sinalizador -type=SRV para obter os números de porta associados a cada um dos nós em seu cluster.

 nslookup -type=SRV _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net

 Server: 127.0.0.53
 Address: 127.0.0.53#53
 Non-authoritative answer:
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1026 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1024 pl-0-us-east-1.k45tj.mongodb.net.
 _mongodb._tcp.cluster0-pl-0.k45tj.mongodb.net service = 0 0 1025 pl-0-us-east-1.k45tj.mongodb.net.

Teste a conectividade.

Em seu ambiente de aplicação , com uma das portas listadas (por exemplo, 1026, 1024 ou 1025 no exemplo de saída acima), execute o seguinte comando telnet para testar a conectividade:

telnet pl-0-<xyz>.mongodb.net 1024
telnet pl-0-<xyz>.mongodb.net 1025
telnet pl-0-<xyz>.mongodb.net 1026

Para visualizar o status de cada endpoint privado:

No Atlas, vá para a página Database & Network Access do seu projeto.

Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione seu projeto no menu Projects na barra de navegação.
Na barra lateral, clique em Database & Network Access sob o título Security.

The Database & Network Access page displays.

Na barra lateral, clique em Private Endpoint.

Revise os status.

Os campos Atlas Endpoint Service Status e Endpoint Status mostram o status de cada endpoint privado.

Consulte os status a seguir para ajudá-lo a determinar o estado de suas conexões de endpoint privado:

Atlas Endpoint Service Status

Status	Descrição
Criando link privado	O Atlas está criando o balanceador de carga de rede e os recursos de VPC .
Falhou	Ocorreu uma falha no sistema.
Disponível	A Atlas criou o balanceador de carga de rede e o serviço de endpoints VPC . O serviço de private endpoint está pronto para receber solicitações de conexão.
Excluindo	O Atlas está excluindo o serviço de endpoint privado.

Endpoint Status

Status	Descrição
Iniciando	O Atlas ainda não está conectado ao seu endpoint privado e ainda não aceitou os endpoints.
Aguardando usuário	Os recursos de VPC no Atlas estão prontos para uso. Configure os endpoints na sua VPC executando o script de shell.
Verificado	Atlas verificou os pontos de extremidade em sua VPC mas ainda não aceitou o ponto de extremidade privado em sua Google Cloud VPC. Pode levar vários minutos para que o Endpoint Status se torne `Available`.
Disponível	Os recursos do Atlas VPC são conectados ao private endpoint em seu Google Cloud Platform VPC. O Atlas aceitou os endpoints. Você pode se conectar a Atlas clusters nessa região usando o GCP Private Service Connect.
Ativo	O Atlas está pronto para usar os recursos da VPC . O Atlas aceitou os endpoints. Uma VM é atribuída à conexão de serviço privado.
Falhou	O Google Cloud falhou ao estabelecer uma conexão entre os recursos da VPC do Atlas e o ponto de extremidade privado na sua VPC do Google Cloud. Clique em Edit, verifique se as informações fornecidas estão corretas e, em seguida, crie o ponto de extremidade privado novamente. Observação: se você vir a mensagem de erro "O ponto de extremidade não pôde ser encontrado no GCP. Verifique se o nome do ponto de extremidade está correto e foi criado no projeto GCP correto e tente novamente," você pode ter digitado incorretamente seu nome de ponto de extremidade privado ou ainda precisa criá-lo. Para resolver isso, clique em Edit e verifique se os campos estão corretos.
Excluído	Você excluiu manualmente o endpoint privado de uma região no Atlas. Você também deve excluir o endpoint privado na Google Cloud Platform para excluir recursos. Exclusão pendente do grupo de regiões.

Aviso

Certifique-se de que seus grupos de segurança estejam configurados corretamente.

Para cada recurso que precisa se conectar ao Atlas cluster usando o GCP Private Service Connect, você deve permitir o tráfego de saída para os endereços IP privados da regra de encaminhamento em todas as portas (1024-65535). Consulte Gerenciando a segurança do consumidor para PSC para obter mais informações.

Endpoints privados de várias regiões

Indexação de connection string para clusters multirregionais

Depois de configurar um endpoint privado para uma nova região e distribuir nós de cluster nessa região, você poderá ver o seguinte erro ao usar seu endpoint privado para se conectar ao cluster:

DNSHostNotFound: Failed to look up service "<MongoDB service name>"

mongodb+srv://cluster1-psc-0.4uyx2d.mongodb.net

mongodb+srv://cluster1-psc-1.4uyx2d.mongodb.net

Teste a conectividade do seu aplicativo implantado

Você pode usar as ferramentas nslookup e telnet para testar a conectividade do seu aplicação com o Endpoint Privado no Atlas.

Obtenha os detalhes da conexão do seu Atlas cluster.

Execute nslookup com o sinalizador -type=SRV para obter os números de porta associados a cada um dos nós em seu cluster.

 nslookup -debug -type=SRV _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net

Server:               127.0.2.2
Address:      127.0.2.2#53
------------
   QUESTIONS:
   _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net, type = SRV, class = IN
   ANSWERS:
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   ->  _mongodb._tcp.cluster1-psc-0.j735c.mongodb.net
   service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
   ttl = 60
   AUTHORITY RECORDS:
   ADDITIONAL RECORDS:
------------
Non-authoritative answer:
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1024 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1025 pl-0-us-central1-gcp.j735c.mongodb.net.
_mongodb._tcp.cluster1-psc-0.j735c.mongodb.net        service = 0 0 1026 pl-0-us-central1-gcp.j735c.mongodb.net.
Authoritative answers can be found from:
telnet pl-0-us-central1-gcp.j735c.mongodb.net 1024

Teste a conectividade.

Em seu ambiente de aplicação , com uma das portas listadas (por exemplo, 27017 no exemplo de saída acima), execute o seguinte comando telnet para testar a conectividade:

telnet pl-0-<xyz>.mongodb.net 27017

Voltar

Gerenciar e conectar

AWS Lambda