-
Notifications
You must be signed in to change notification settings - Fork 70
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
feat: port forwarding support #60
Conversation
Thanks! I don't work on this library too much anymore tbh. But I think the best way to do this is to stop making |
Let me know if I'm mistaken, but it looks like zero values for As an alternative... in this PR there are a lot of duplicate fields between the "Forward" and "Listen"-type structs (I did a quick and dirty hack here to get cmars/oniongrok working). What if we refactor this into common "HiddenService"-config related structs, and embed in both types (Listen- and Forward-related) of structs? And then refactor out the common bits among Tor.Forward / Tor.Listen into private methods? That way Listen can be all about setting up a hidden net.Listener, Forward can be just about local port forwards, and they can reuse all the common parts (setting up a hidden service in Tor). I think either way, we're likely looking at a breaking API change. |
@cmars - Hrmm, that seems true. I had a whole thing typed out about how we could reuse
After some thought, I agree with the idea but not exactly the impl. I don't think we want embeds (just copy the common fields, embeds is a backwards incompat change), but reusing any code internally is very reasonable if at all possible. So, really, revisiting this PR, I think it's mostly good :-) Thanks for going in circles here with me, heh. I do think You may also want an integration test or two to confirm it works. |
097b38e
to
dc9a70f
Compare
@cretz Updated the port mapping -- I found that it needs to be a I've tested this in cmars/onionpipe#1 and it seems to work. What do you think? I started going further down the path of refactoring out common parts in Listen and Forward. I think it's doable, but I'm getting quite a bit worried about landing such a drastic change without unit test coverage. Something to revisit in a followup? |
dc9a70f
to
a3ffbbf
Compare
|
||
// Forward as an onion service on test ports | ||
conf := &tor.ForwardConf{ | ||
Version3: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that v2 services are past sunset and current releases of Tor will not allow these to be published. Integration tests which attempt to resolve or publish v2 hidden services are currently failing. I'll have a fix for these in a followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Could do some refactoring of Listen/Forward. If this is generally a good idea happy to tidy things up.