-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[QUESTION] Support for Azure SNI connection through tunnel #1678
Comments
I added tediousConnection.on('debug', (txt) => logDebug(txt));
tediousConnection.connect((e) => {
if (e) {
logError(e.message);
}
});
tediousConnection.on('connect', (e) => {
logDebug('connected!');
if (e) {
logError(e.message);
}
}); to try debug some of the info exchanged by tedious and see the following in the logs:
so it looks like it might be somewhere in the login step there? Will try compare with the working example now |
I think the incorrect packet there is the Line 2487 in ebb023e
in the mean time, I have patched it so that |
Question
I'm connecting to a Azure MS SQL database through the use of a GCP IAP tunnel.
Our IAP tunnel is configured via
socat
to forward requests from port 5432 toxxxx.database.windows.net:1433
. This connection works fine.On local dev machines, I am trying to use tedious to connect to the database (by first going through the iap tunnel), with Azure Active Directory Service Principle credentials.
I suspect that somewhere in the secret exchange done in Tedious, it fails to authenticate (maybe due to an invalid SNI?).
Here's the config that works:
this only works once I edit
/etc/hosts
withbecause the SNI matches (as I understand) which prevents a cert refusal somewhere in the chain. This works because (to my understanding) tedious will perform the request to
xxxx.database.windows.net
, and my OS will route that to127.0.0.1:5432
, which goes through an iap tunnel and out toxxxx.database.windows.net
from an authenticated IAP host. Since the original request was forxxxx.database.windows.net
, all cert checks match.Problem
It would be nice if I didn't have to edit my
/etc/hosts
to do this mapping, and instead tedious could somehow perform this authentication handshake with Azure before then using my local tunnel for all database queries. I am wondering if this is currently possible, or where the blocking issue is?For example, if I adjust the connection to
I will get the following output:
but I see on my iap tunnel (via socat logging) that some requests have indeed been forwarded successfully.
I'm wondering if anyone has experienced this, or has any ideas for how to resolve this such that developers don't have to modify
/etc/hosts
to get the requests working?The text was updated successfully, but these errors were encountered: