I have a question about whether sql-proxy could be adapted to also help with another use case we have.

We plan to implement a feature to help users migrate data from an external MySQL instance (e.g. RDS) into PSDB. In PSv1, we did this by directly connecting out from our infrastructure to an address provided by the user, but it had two problems we never fully solved:

1. We had to ask users to open up their database to connections from the public internet. We could give them a list of our possible source IPs, but this was still a hard sell especially when it came time to connect to their production database. We also couldn't completely guarantee that the set of IPs would never change, since we might need to add more over time.
2. Making outgoing connections from our infrastructure to an arbitrary, user-provided address created a security risk for us. The user might be able to trick us into connecting to one of our own services that would see the traffic as coming from a host inside our own network. We used network egress policies to block connections to private IPs, but the risk still existed for any VMs or other endpoints in our VPC that also had public IPs.

Could we adapt sql-proxy to make the tunnel usable in the reverse direction as well, to facilitate outgoing connections from PSDB to an endpoint in the user's private network?

I'm imagining something like this:

1. User runs sql-proxy-client in their private network, which has access to their current production database. They configure it for "inbound" mode and point it at the desired database endpoint.
2. This agent connects out from the user's network to a PSDB endpoint to establish a tunnel through which TCP connections could be established.
3. When PSDB needs to connect to the user's database, it actually connects to a PSDB-internal endpoint to request that a particular user-established tunnel be used.

What do you think?