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.