Is your feature request related to a problem? Please describe.
When tunneld runs on a different network stack then the client ( e.g. different docker network or different host altogether ), the returned RSD endpoints are useless as the client doesn't have access to such interfaces.
Describe the solution you'd like
Add a /connect endpoint ( or any other name ) to enable the client to connect to the tunnel interface through tunneld HTTP API, removing the need to share the same network stack.
Describe alternatives you've considered
To achieve this, it would be possible to use MASQUE over HTTP/3, which enable the client to use the tunnel interface over HTTP.
Alternatively, it would be possible to use the SOCKS5 proxy protocol.
I haven't explored all the options nor their feasibility in detail tho.
Additional context
If #1647 is taken care of, tunneld itself looses its utility for pymobiledevice library users, making this request irrelevant for such cases.
However, for other users that might use tunneld for other purposes, this feature might still be useful.
Given the sensitivity of the services exposed over the tunnel, an authentication mechanism shall prevent unauthorized connections.
For community
⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment
Is your feature request related to a problem? Please describe.
When
tunneldruns on a different network stack then the client ( e.g. different docker network or different host altogether ), the returned RSD endpoints are useless as the client doesn't have access to such interfaces.Describe the solution you'd like
Add a
/connectendpoint ( or any other name ) to enable the client to connect to the tunnel interface throughtunneldHTTP API, removing the need to share the same network stack.Describe alternatives you've considered
To achieve this, it would be possible to use MASQUE over
HTTP/3, which enable the client to use the tunnel interface over HTTP.Alternatively, it would be possible to use the SOCKS5 proxy protocol.
I haven't explored all the options nor their feasibility in detail tho.
Additional context
If #1647 is taken care of,
tunnelditself looses its utility for pymobiledevice library users, making this request irrelevant for such cases.However, for other users that might use
tunneldfor other purposes, this feature might still be useful.Given the sensitivity of the services exposed over the tunnel, an authentication mechanism shall prevent unauthorized connections.
For community
⬇️ Please click the 👍 reaction instead of leaving a
+1or 👍 comment