[EXPERIMENTAL] prototyping a next-generation cross-platform outline client with the sdk #193
Conversation
daniellacosse
changed the title
Co-authored-by: J. Yi <[email protected]>
Co-authored-by: J. Yi <[email protected]>
…gsaw-Code/outline-internal-sdk into daniellacosse/outline-vpn-app
| // => kotlin box uses SSH tunnel (for now) | ||
|
|
||
| // ! these boxes will be reusable across VPN apps ! | ||
| http.NewRequest("POST", systemTunnelEndpoint, vpn.tunnel) |
There was a problem hiding this comment.
@jyyi1 is this sufficient or do I need to actually execute the request?
There was a problem hiding this comment.
Looks good, but the request might return permission error, in this case the app should handle it (e.g., navigate to the permission approval settings page in Android, or pop-up a dialog in Linux to enter the root password).
There was a problem hiding this comment.
The permission stuff I envision being handled by the service itself, but I should definitely be handling the error.
| vpn.tunnel = tunnel | ||
|
|
||
| // TODO: implement system vpn tunnel service | ||
| // => POST /tunnel/URL forward all non-local traffic to that URL |
There was a problem hiding this comment.
@jyyi1 Am I thinking about the tunnel and proxy the right way here?
There was a problem hiding this comment.
The Tunnel here is more like a system VPN configuration, typically it involves the source and the target. The source can be simple, like "all non-local TCP and UDP traffic from the system", or it can be complicated, such as "all UDP traffic destined to 8.8.8.8 from a specific app". The target would typically be represented by IP:port instead of a URL. But here I guess you will setup a local proxy to handle the traffic.
For the simplicity, I think we can start with source=all TCP & UDP and target=127.0.0.1:<proxy-port>. And we need to provide different implementations for different OS.
There was a problem hiding this comment.
Okay cool. The idea is that the OS-specific logic will live behind this service we create that I am gonna stub out for now.
Is there a material difference between what the tunnel in tun2socks does and what a system VPN configuration does? Functionally it's sort of the same goal, no?
There was a problem hiding this comment.
Yes. At least for Windows and Linux there are no differences. But on Android and iOS, we need to adapt to the VPN API provided by the system.
There was a problem hiding this comment.
Got it, so conceptually it's the same, it's just on mobile the tunnel is done through the VPN APIs.
| vpn.tunnel = tunnel | ||
|
|
||
| // TODO: implement system vpn tunnel service | ||
| // => POST /tunnel/URL forward all non-local traffic to that URL |
There was a problem hiding this comment.
The Tunnel here is more like a system VPN configuration, typically it involves the source and the target. The source can be simple, like "all non-local TCP and UDP traffic from the system", or it can be complicated, such as "all UDP traffic destined to 8.8.8.8 from a specific app". The target would typically be represented by IP:port instead of a URL. But here I guess you will setup a local proxy to handle the traffic.
For the simplicity, I think we can start with source=all TCP & UDP and target=127.0.0.1:<proxy-port>. And we need to provide different implementations for different OS.
| // => kotlin box uses SSH tunnel (for now) | ||
|
|
||
| // ! these boxes will be reusable across VPN apps ! | ||
| http.NewRequest("POST", systemTunnelEndpoint, vpn.tunnel) |
There was a problem hiding this comment.
Looks good, but the request might return permission error, in this case the app should handle it (e.g., navigate to the permission approval settings page in Android, or pop-up a dialog in Linux to enter the root password).
currently have a go web app rendering on web, android:
and apple (mac catalyst):
next steps: