Can't connect to a mongo cluster(by IPs) which address is behind a vpn

[kakoc]

Hi,

I'm trying to connect to a replica set by IPs which is behind VPN.

    let client = Client::with_uri_str("mongodb://name:[email protected]:27017,xx.xx.xx.xxx:27017,xx.xx.xx.xxx:27017/?tlsallowinvalidcertificates=true&replicaSet=repl-set-name").expect("db client created");

    for db_name in client
        .list_database_names(None, None)
        .expect("database names fetched")
    {
        println!("{}", db_name);
    }

I receive the following error:

Error { kind: ServerSelection { message: "Server selection timeout: No available servers. Topology: { Type: ReplicaSetNoPrimary, Servers: [ { Address: xx.xx.xx.xxx:27017, Type: Unknown, Error: An error occurred during DNS resolution: InvalidDNSNameError }, { Address: xx.xx.xx.xxx:27017, Type: Unknown, Error: An error occurred during DNS resolution: InvalidDNSNameError }, { Address: xx.xx.xx.xxx:27017, Type: Unknown, Error: An error occurred during DNS resolution: InvalidDNSNameError }, ] }" }, labels: {} }

mongo-rust-driver version: 2.0.0
MongoDB version: 3.6.20

using mongo shell with the following format I can successfully connect(self signed cert is used):

mongo --sslAllowInvalidHostnames --ssl --authenticationDatabase 'admin' --host repl-set-name/xx.xx.xx.xxx:27017,xx.xx.xx.xxx:27017,xx.xx.xx.xxx:27017 -u user -p passwd

What I'm doing wrong?

[WindSoilder]

Oh.... I get similar issue in #478, but in my scenario, I doubt it's because of my mongodb version too low...

[wishawa]

Try using direct connection.

[kakoc]

Try using direct connection.

I don't understand how that option could potentially help. But I tried and got the same result.

[wishawa]

Try using direct connection.

I don't understand how that option could potentially help. But I tried and got the same result.

It tells the client not to try to do network topology discovery or any of that stuff and just connect to the given ip/domain. It worked for me, at least.

[patrickfreed]

The Server Discovery and Monitoring specification (SDAM) requires that drivers connect to and monitor the address provided in the me field of the response to an isMaster or hello command for an individual node, even if it differs from what is provided in the seed list of the connection string. See the rationale for this here.

It's possible that the addresses provided via the URI are different than the ones the servers report themselves as being located at, and the driver can't reach the self-reported addresses. When you connect with the shell and run db.runCommand({ isMaster: 1 }), does the me field match that of the address provided in the connection string?

[kakoc]

The Server Discovery and Monitoring specification (SDAM) requires that drivers connect to and monitor the address provided in the me field of the response to an isMaster or hello command for an individual node, even if it differs from what is provided in the seed list of the connection string. See the rationale for this here.

It's possible that the addresses provided via the URI are different than the ones the servers report themselves as being located at, and the driver can't reach the self-reported addresses. When you connect with the shell and run db.runCommand({ isMaster: 1 }), does the me field match that of the address provided in the connection string?

Addresses are the same.

BTW, I also tried to connect to the mentioned replica set via node.js application(mongodb npm package) and successfully connected(the same connection uri + ?tlsAllowInvalidHostnames=true).

[patrickfreed]

So the issue appears to be that the DNS name provided isn't considered valid according to the TLS libraries the driver uses (webpki and rustls). You can verify this manually by adding webpki as a dependency and passing your address string into DnsNameRef::try_from_ascii_str. Perhaps the addresses provided to the connection string are formatted incorrectly? If so, you can fix them up and the driver should start working.

If they are formatted correctly but are just in a format that rustls doesn't accept, then unfortunately there doesn't seem to be a workaround here, since rustls doesn't expose a way for us to implement tlsAllowInvalidHostnames=true.

[kakoc]

So the issue appears to be that the DNS name provided isn't considered valid according to the TLS libraries the driver uses (webpki and rustls). You can verify this manually by adding webpki as a dependency and passing your address string into DnsNameRef::try_from_ascii_str. Perhaps the addresses provided to the connection string are formatted incorrectly? If so, you can fix them up and the driver should start working.

If they are formatted correctly but are just in a format that rustls doesn't accept, then unfortunately there doesn't seem to be a workaround here, since rustls doesn't expose a way for us to implement tlsAllowInvalidHostnames=true.

Seems that the issue is related to jasonish/evebox#148.
We will try to use a domain name with srv instead. I'll update the issue as results will be available.

[patrickfreed]

Yeah that does seem to be the same issue, the root of which is briansmith/webpki#54. Since this is an issue with the underlying TLS library, I'm going to close it in favor of #499. Hopefully using the SRV URI will work for you, and please let us know if you have any further questions!