Skip to content
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

don't pick IP of first Network inside docker-gen template #3

Closed
langfingaz opened this issue Sep 12, 2020 · 2 comments
Closed

don't pick IP of first Network inside docker-gen template #3

langfingaz opened this issue Sep 12, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@langfingaz
Copy link
Contributor

First: Thanks for this great project!

Summary: If the container providing a web service (e.g. service1) is connected to multiple docker networks (and has thus multiple IP addresses - one for each network), then the current torrc.tmpl will "randomly" choose one of the service1 IP addresses. This way it can happen, that onionize can't reach service1 on the chosen IP address as this IP address is from a network that onionize is not connected to.

Example

The web service 'service1' is available on the clearnet but to further respect the privacy of any visitors, they can also access it as an onion service.

  • docker-compose.yml
version: '3'

services:
  onionize:
    container_name: onionize
    build: .
    restart: always
    volumes:
          - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      - tor

  service1:
    image: ...
    expose:
      - 80
    environment:
      ONIONSERVICE_NAME: "service1"
    networks:
      - tor
      - clearnet_proxy

  proxy:
    image: nginx
    ports:
      - 80
      - 443
    environment:
    networks:
      - clearnet_proxy

onionize can only reach service1 via the tor network both containers are connected to.

If one restarts service1, the torrc file gets regenerated from the template. And the line HiddenServicePort 80 <IP>:80 inside torrc will sometimes have an IP starting with 172 (clearnet_proxy) or starting with 192 (tor).

If the first is the case, one can not reach the onion service. Only in the second case everything works as expected.

Possible Solution

One could use the container name variable (of service1) in the template file instead of choosing the IP address of the first network ({{ $network := index $value.Networks 0 }}, HiddenServicePort {{ $address.Port }} {{ $network.IP }}:{{ $address.Port }}) to communicate with it.

This would e.g. result in the following line inside torrc:

HiddenServicePort 80 service1:80

I tested this for my example (disabled docker-gen) and manually created the torrc file and it worked fine.

Alternative Solution

Another approach would be to iterate over the Networks array of RuntimeContainer and for each network check if the Network.Name matches any of the networks that onionize is connected to. If there is a match, take the IP address from that network.

@moba
Copy link
Member

moba commented Sep 12, 2020

Thanks for outlining the problem and possible solutions in such a comprehensive way! It sounds like using the container name is indeed the cleaner way to approach this.

Pull requests welcome, otherwise I will see when I can find the time to address this myself.

@moba moba added the bug Something isn't working label Sep 12, 2020
langfingaz added a commit to langfingaz/onionize-docker that referenced this issue Sep 12, 2020
Change template according to torservers#3 

Instead of `{{ $value.Name }}` one could also use `{{ $value.Hostname }}`

**Note**: I hope these changes are ok. A quick test with my example setup from torservers#3 worked. But this is the first time I work with a `docker-gen` template. Please review.
moba pushed a commit that referenced this issue Sep 12, 2020
Change template according to #3 

Instead of `{{ $value.Name }}` one could also use `{{ $value.Hostname }}`

**Note**: I hope these changes are ok. A quick test with my example setup from #3 worked. But this is the first time I work with a `docker-gen` template. Please review.
@moba
Copy link
Member

moba commented Sep 12, 2020

I played around with it a bit, and thought about it for a while, and I'm sufficiently confident now that this will work -- pushing a new release :) Thanks!

@moba moba closed this as completed Sep 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants