Timeline for How can I verify that TransPort is working correctly?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2018 at 23:13 | comment | added | user569825 | That's the container source: github.com/flungo-docker/tor-router (Dockerfile at github.com/flungo-docker/tor-router/blob/master/src/Dockerfile) | |
| Feb 20, 2018 at 21:39 | comment | added | cacahuatl | SOCKS would work, TransPort works on an entirely different principle. If you could add a mock-up of your Dockerfile I can take another look and see if I can find anything, though. | |
| Feb 20, 2018 at 21:21 | comment | added | user569825 |
With your script, docker-proxy is indeed fired up and I get FileNotFoundError: [Errno 2] No such file or directory on line 10 (orig = ...) once I execute the curl command on the host. Also, if I do run the tor-router image with -p "9040:9040", docker-proxy does pop up in the process table, but the behaviour doesn't change at all (curl still hanging). Important to mention that curl --proxy socks5h://${TOR_ROUTER_IP}:9050 https://check.torproject.org/api/ip does work regardless of using any -p or not - without docker-proxy - meaning 9050 is available on host.
|
|
| Feb 20, 2018 at 0:50 | comment | added | cacahuatl | What happens if you run my script in the same situation? | |
| Feb 19, 2018 at 19:40 | comment | added | user569825 |
According to some research and further tests, docker-proxy is not active at all. The issue is most likely caused elsewhere.
|
|
| Feb 17, 2018 at 14:43 | comment | added | cacahuatl | I don't know enough about Docker internals to answer definitively but I think if both host and container share the same network interface so they both see the same connection, then it should work. | |
| Feb 17, 2018 at 14:08 | comment | added | user569825 | Got it. So, in theory, if, instead of bridged networking, I'd go for the macvlan or, preferably, the overlay driver, the issue should be avoidable? (docs.docker.com/network/overlay) | |
| Feb 17, 2018 at 0:31 | comment | added | cacahuatl |
No, when the REDIRECT is applied the original destination is still kept in the kernel's conntrack table. When Tor receives a connection to it's TransPort it can use getsockopt() to lookup the original destination (not Tor's Transport). Because the container gets it's traffic via docker-proxy it takes in a connection from outside of the container, and makes a connection inside of the container and bridges the two. Tor gets the connection from docker-proxy and so can't lookup the original destination because it's not the same connection, it's a new one docker-proxy made.
|
|
| Feb 16, 2018 at 22:43 | comment | added | user569825 | I'm failing to understand fully yet. So conntrack basically says "check.torproject.org is 172.17.0.2" and thus the container tries to talk to that IP instead of the correct one (138...)? Any way to tackle the situation regardless? | |
| Feb 14, 2018 at 21:55 | history | edited | cacahuatl | CC BY-SA 3.0 |
explained weird constant
|
| Feb 14, 2018 at 20:45 | history | answered | cacahuatl | CC BY-SA 3.0 |