feature: proxy requests back through tunnel to originate from lambda execution environment

[rogerchi]

I wonder if it would be possible to proxy requests originating from the local debug environment back through the IOT tunnel and originate them from the lambda execution environment? A few different use cases we have for this:

• We use the Lambda Secrets Extension which runs a local listener in the lambda environment to provide cached secrets
• We have various Lambdas that are deployed inside VPCs so that they can connect to resources inside private networks

reference: https://www.frodehus.dev/debugging-web-requests-using-mitmproxy-wsl-and-vscode/

[ServerlessLife]

That is a brilliant idea. 💡

I am not sure how hard it would be to implement that. For HTTP traffic, it would probably be easier, but for TCP (like SQL database connection), it could be a bit challenging. I will explore it further.

[ServerlessLife]

I found quite some npm libraries that can intercept either HTTP or TCP requests or both:
https://www.npmjs.com/package/mitm ⭐
https://www.npmjs.com/package/@mswjs/interceptors
https://www.npmjs.com/package/node-request-interceptor
https://www.npmjs.com/package/@gr2m/net-interceptor

Using them would probably not be that hard to implement the functionality. The Lambda handler runs in a Node Worket Thread, so it is isolated, and any HTTP/TCP interception would probably not cause other issues on the Lambda Live Debugger.

[rogerchi]

mitm looks perfect

[ServerlessLife]

I played with this for some time and think it's doable.
The mitm library looks like the way to go, although it is not well maintained. I instantly found this issue: moll/node-mitm#42 (comment), which blocked me for some time. But I found an easy workaround.

The TCP also intercepts HTTP connections, so there would be one solution for both.

I see the most value when using SQL database or Redis in VPC. Resolving issues with any other connection within VPC or using the Lambda Secrets Extension would also be very valuable.

[ServerlessLife]

@rogerchi
I spent quite some time researching this. I created a sample that intercepts TCP and HTTP requests in a node worker thread, forwards them to the parent process, and returns the response to the thread.

That works for a simple scenario. But it does not if you use real-case scenarios like connecting to an SQL database. SQL clients have complicated connection pooling. I do not think it is possible to do this without patching the SQL client library. That would, of course, require a lot of work.

The TCP traffic is the most interesting because you can connect to the SQL database. HTTP does not seem that useful, except for Lambda Secrets Extension.

I will not be proceeding with this, at least for now.