Can Indy TIdMappedPortTCP be used as a server side proxy?

[BosseB]

This is a question relating to my thread How to create a "TCP/IP relay" server? on this forum. I decided to spawn it since it relates to a specific Indy component...

I need to create a connection point for access to a TCP server in my application. The normal way would be to just start listening on a specific TCP port in the application and wait for a client to connect.

But this is not possible since the network router the application is behind is not given a public IP address so I cannot port forward from the router to the device where the application runs (a RaspberryPi).

I am using the Indy10 networking components and it has a mapping utility named TIdMappedPortTCP but I cannot find any examples of usage unfortunately...

What I have in mind is to make a relaying application, which would run on another Raspberry Pi server which does have a public IP address into the network it is on.

This application will have two socket connections, one for the "hidden" server on the other network to connect to and the other for the actual client to connect to.

When the main "hidden" application starts up it would connect to the "server" port of the  relay application and then wait for data to arrive.
Now any application that needs to talk to the "hidden" application will connect to the relaying app on its "client" port and this app will forward whatever is sent to the server connected to its "server" port.

When I asked this on the Indy forum I did not know of TIdMappedPortTCP but got a short answer that it exists but no other clue as to its usage...

So my question is this:
Can TIdMappedPortTCP be used for the purpose described above or do I need another solution?
It seems like it is designed to go the "other way", i.e. to allow a connection to be done from a client to a server by redirecting the socket connection from the client...

All other solution suggestions should be discussed in my other thread. Like using SSH or VPN and the like.

[Remy Lebeau]

This is a question relating to my thread How to create a "TCP/IP relay" server? on this forum. I decided to spawn it since it relates to a specific Indy component...

Asked and answered in the AToZed forum thread you created earlier.

[dseligo]

This is a question relating to my thread How to create a "TCP/IP relay" server? on this forum. I decided to spawn it since it relates to a specific Indy component...

Asked and answered in the AToZed forum thread you created earlier.

I don't have account in atozed forum, so I'll comment here.
I think you didn't understand OP's problem.
Dynamic IP address of client (RPi4) is not the issue here, issue is that the RPi4 has no public IP address. You can't connect to RPi4 from outside with IP address. RPi4 has to connect to the relay server and client computer also has to connect to the relay server. So relay server must have two incoming connections and relay traffic between them.

[Remy Lebeau]

I think you didn't understand OP's problem.

I understand the OP's problem just fine, thank you.

Dynamic IP address of client (RPi4) is not the issue here, issue is that the RPi4 has no public IP address. You can't connect to RPi4 from outside with IP address.

The OP clearly stated in their first post that the RPi4 is running a socket server, it just does not have an accessible public IP, which makes total sense when the RPi4 is running on a mobile network.  But it still has to have a local IP to listen on.

RPi4 has to connect to the relay server and client computer also has to connect to the relay server.

Even if the RPi4 were acting as another client to the relay, that would still require the RPi4 to have a local IP assigned.  That is a base requirement of TCP/IP.  In which case, if the RPi4 can reach the relay as a client of the relay's server, then the relay can reach the RPi4 as a client of the RPi4's server, if the relay and RPi4 are connected to the same network.

So relay server must have two incoming connections and relay traffic between them.

Not given the description the OP originally provided.  But, even if what you say is true, that is still possible to handle with Indy, but just not with TIdMappedTCP as it is not designed for relaying client-to-client, only client-to-server.  You would have to use TIdTCPServer instead and manually handle the back-and-forth between clients in its OnExecute event.

[PascalDragon]

RPi4 has to connect to the relay server and client computer also has to connect to the relay server.

Even if the RPi4 were acting as another client to the relay, that would still require the RPi4 to have a local IP assigned.  That is a base requirement of TCP/IP.  In which case, if the RPi4 can reach the relay as a client of the relay's server, then the relay can reach the RPi4 as a client of the RPi4's server, if the relay and RPi4 are connected to the same network.

That is not necessarily true. E.g. I myself am connected to the internet with a DualStack-lite. So while I can access other servers with both IPv4 and IPv6 only IPv6 can be used to reach me, because IPv4 is behind a NAT.

[Thaddy]

That is not necessarily true. E.g. I myself am connected to the internet with a DualStack-lite. So while I can access other servers with both IPv4 and IPv6 only IPv6 can be used to reach me, because IPv4 is behind a NAT.

It is true. There's a technique called "hole punching" available for TCPv4 that is widely used. E.g. WhatsApp, Telegram, etc. Behind a NAT is usually not a problem. And FPC -fcl-web/net - supports this technique too.
https://en.wikipedia.org/wiki/Hole_punching_%28networking%29

Note: AllowRedirects should be true.

[BosseB]

Remy's response on Atozed clarified the way to move forward.
I will drop the relayer idea for the moment.

Instead I will investigate an OpenVPN solution where the RPi4 would connect automatically (via a daemon perhaps) at all times and the client in preparation to talking to the RPi4.

The VPN will not route anywhere so its only purpose is to set up the common network (AKA the Tunnel) on which the interchanges will be done between VPN connected parties only.

This is not a public system so I don't need (or want) the comm to go outside of the tunnel.

[dseligo]

In which case, if the RPi4 can reach the relay as a client of the relay's server, then the relay can reach the RPi4 as a client of the RPi4's server, if the relay and RPi4 are connected to the same network.

They are not connected to the same network.

[dseligo]

And FPC -fcl-web/net - supports this technique too.

Is there some example for this technique using FPC? It would be very interesting.