Skip to content

oauthutil: listen on ipv4 & ipv6 with mulitlistener #8733

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

tonymet
Copy link
Contributor

@tonymet tonymet commented Aug 6, 2025

What is the purpose of this change?

Support IPv6 Bind Address for Oauth authentication server. This allows for e2e IPv6 connections.

  • Works for machines with only IPv6 interface (e.g. EC2 without public IPv4 address)
  • Supports IPv6 SSH tunnel with ssh -6 -L53682:localhost:53682
  • Prefers ipv6 when available
  • user is only exposed to "localhost" -- no clumsy [::1] addresses are shown

See also #7537 a previous attempt with some discussion. This approach by using multilistener is cleaner.

About dualstack/multilistener

About IPV4 / IPV6 listening on localhost being tricky

Apprently this challenge goes down to the kernel level in net/ipv6/af_inet6.c that listening to all interfaces e..g [::] would support dual stack, but a specific net addr would be only single-stack. There seems to have been a lot of discussion about single stack loopback

e.g.

[drive-test]
type = drive

Alternatives

  • use net.Listen("tcp", ":53682") to listen on all interfaces ipv4 & ipv6 . this opens a small security risk of listening on external interfaces. we could mitigate this will application code socket filter in middleware/FirewallListener. this would the simplest and easiest to debug.
  • use net.Listen("tcp", "localhost:53682") to allow system NS to return the right interface. This should work ipv6 & ipv4, but may not work for ssh tunneling (user would need to use netstat to see which interface is listening)
  • ❌status quo = don't support ipv6

Part of IPv6 E2E support for Rclone:

Was the change discussed in an issue or in the forum before?

https://forum.rclone.org/t/ipv6-guide-review-with-google-drive-ec2-s3/43218

Testing

  1. Run go run . config and configure "drive" backend with
$ go run . config 
2025/08/06 22:10:18 NOTICE: Make sure your Redirect URL is set to "http://localhost:53682/" in your custom config.
2025/08/06 22:10:18 ERROR : Failed to open browser automatically (exec: "xdg-open": executable file not found in $PATH) - please go to the following link: http://localhost:53682/auth?state=7kRTMtCNY7gqFie9ysuOjQ
2025/08/06 22:10:18 NOTICE: Log in and authorize rclone for access
2025/08/06 22:10:18 NOTICE: Waiting for code...
2025/08/06 22:10:27 NOTICE: Got code

Hit CTRL-Z to background the process

Run netstat (below) to confirm tcp6

You should see tcp6 and "[::1]:*" in netstat when binding with ipv6 address

$  sudo netstat -tulp|grep rclone 
tcp        0      0 127.0.0.1:53682         0.0.0.0:*               LISTEN      2530/./rclone
tcp6       0      0 ::1:53682               :::*                    LISTEN      2530/./rclone

Checklist

  • [ ✅] I have read the contribution guidelines.
  • I have added tests for all changes in this PR if appropriate.
  • [ ✅] I have added documentation for the changes if appropriate.
  • [ ✅] All commit messages are in house style.
  • I'm done, this Pull Request is ready for review :-)

@tonymet tonymet changed the title listen on ipv4 & ipv6 with mulitlistener oauthutil: listen on ipv4 & ipv6 with mulitlistener Aug 6, 2025
@darthShadow
Copy link
Member

Would it be possible to just add a copy of the relevant library functions rather than adding a new dependency?

@tonymet
Copy link
Contributor Author

tonymet commented Aug 7, 2025

Would it be possible to just add a copy of the relevant library functions rather than adding a new dependency?

I'm open to it. it would probably be best to vendor it which would prevent code drift / forking. I don't expect any patching being needed within the private implementation. vendoring would make updates a lot easier.

Let's see what's needed for testing and making the feature mature, and when things are stable I think vendoring would be easy.

@tonymet
Copy link
Contributor Author

tonymet commented Aug 7, 2025

I added an "Alternatives" section to think through other approaches, like net.Listen("tcp", ":" + PORT)

@tonymet
Copy link
Contributor Author

tonymet commented Aug 12, 2025

Please review the "Alternatives" section. IMO net.Listen("tcp", ":53682) is the most compatible.

Think about which Alternatives would be a good fit and I can cater the PR to the best solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants