docker-compose dynamic IP problem

[loop0day]

Branch: master.

I reduce the numbers of authority servers to reproduce the problem clearly.

version: '3'
services:
 da1:
  image: antitree/private-tor
  #expose:
  #  - "7000"
  #  - "9030"
  environment:
    ROLE: DA
  volumes:
    ## Needed to keep track of other nodes
    - ./tor:/tor
 relay:
  image: antitree/private-tor
  #expose:
  #  - "7000"
  #  - "9030"
  environment:
    ROLE: RELAY
  volumes:
    - ./tor:/tor
  depends_on:
    # Make sure the DA's are already up
    - da1
 exit:
  image: antitree/private-tor
  #expose:
  #  - "7000"
  #  - "9030"
  environment:
    ROLE: EXIT
  volumes:
    - ./tor:/tor
  depends_on:
    # Make sure the DA's are already up
    - da1
 client:
  image: antitree/private-tor
  ports:
    # Setups a listener on host machine
    - "9050:9050"
    - "9051:9051"
  volumes:
    - ./tor:/tor
  environment:
    ROLE: CLIENT
  depends_on: 
    - da1
 hs:
  image: antitree/private-tor
  #expose:
  #  - "80"
  environment:
    ROLE: HS
    # This will create a hidden service that points to
    # the service "web" which is runing nginx. You can 
    # change this to whatever ip or hostname you want
    TOR_HS_PORT: "80"
    TOR_HS_ADDR: "web"
  volumes:
    - ./tor:/tor
  depends_on:
    - da1
  links:
    - web
 web:
  image: nginx
  #expose:
  #  - "80"

Build it with the new up command with --scale flag(leave client offline now).

$ docker-compose up -d --scale client=0 --scale relay=3 --scale exit=3

da1 log output shows the server starts correctly.

da1_1 | May 18 12:05:01.000 [notice] Bootstrapped 100%: Done

Restart the services.

$ docker-compose stop
Stopping tor_relay_2 ... done
Stopping tor_hs_1    ... done
Stopping tor_relay_3 ... done
Stopping tor_exit_1  ... done
Stopping tor_exit_3  ... done
Stopping tor_relay_1 ... done
Stopping tor_exit_2  ... done
Stopping tor_web_1   ... done
Stopping tor_da1_1   ... done

$ docker-compose start
Starting da1    ... done
Starting relay  ... done
Starting exit   ... done
Starting client ... failed
Starting web    ... done
Starting hs     ... done

da log output shows that the dynamic ip address of the scale command confuses the authority server.

da1_1 | May 18 12:10:38.000 [warn] Tried connecting to router at 172.24.0.4:7000, but RSA + ed25519 identity keys were not as expected: wanted 2F159F06AB914C10DF4470A9D1CE00DCCF977C9F + mKjfetwSu6ORRHQ4r8CBFY8rKh1yqBCET5w6bWark4E but got 9E811E6570880ABB5792FE664FD3B53E914B3393 + b7s4R/pE3ZAjVp9cSf5bN6m33c2Tp4MWposRD2ADO0E.

Suppose client joins the private network now.

$ docker-compose up client

Socks port is already opened.

$ ss -anlt
State         Recv-Q         Send-Q                     Local Address:Port                   Peer Address:Port            
LISTEN        0              128                                    *:9050                              *:*             
LISTEN        0              128                                    *:9051                              *:* 

Connection is blocked here.

$ curl --socks5 127.0.0.1:9050 www.google.com

Maybe the scale command is not suitable for building a private tor network here until it can persist the network status.

Thank you for reading.

[zainakh]

Ran into this issue on various Ubuntu VM's and haven't been able to get the repo to work as intended due to it. Wonder if there is a workaround that anybody has found.