Easy-provider regularly binds vdp manager to a non-existent adapter ip

[bodane]

Upon building a node using docker a few times from scratch I've noticed a possible reason for the vdp manager service not publishing itself or being accessible right away. This is while using defaults and not changing the default vdp settings - see workarounds to issue port deployment which worked for me.

The easy provider configuration process can repeatedly publish the local vdp on an interface ip address which doesn't exist in the container. At times this can match up perfectly during deployment but found this rarely does.

Below demonstrates the issue and a present workaround:

• In this test the docker container is run in node mode and "Easy-provider" sets up 100.66.0.3 as the manager-url (can change each deployment of the container which is normal), and sets up endpoint proxies on the same IP for ports 8887 and 8880 as shown below.
• Thereafter I check the local containers lvpnc_30925fcc adapter which has an IP address of 100.66.0.4.
• I then manually re-run generate-vdp referencing all the same details while only updating the IP address syntax to match the local lvpnc_30925fcc adapter IP. The vdp manager then becomes accessible.
• Without the manual re-binding to a valid adapter ip, important commands such as push-vdp fail since the manager is bound to 100.66.0.3 (https://100.66.0.3:8881) which doesn't exist.

docker run -d \
  --rm --name letheannode \
  -v ~/lvpn:/home/lvpn \
  --sysctl net.ipv6.conf.all.disable_ipv6=0 \
  --cap-add=NET_ADMIN \
  -p 8880:8880 \
  -p 8881:8881 \
  -p 127.0.0.1:8123:8123 \
  -p 127.0.0.1:8124:8124 \
  -p 127.0.0.1:8080:8080 \
  limosek/lvpn:dev node

$ docker logs -f letheannode
...
... other output omitted ...
...
.
OK
Waiting for working WG session.
.
.
.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1275  100  1275    0     0  10753      0 --:--:-- --:--:-- --:--:-- 10805
OK (IP=100.66.0.3)
Running easy-provider
...
... other output omitted ...
...
lmgmt generate-vdp Easy-provider-f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab free 100.66.0.3 iz652MfZBxjC8AVpSHHnby8RsHpqox2SMBF7AWGPtnQU8DKmEdoL6k161TxwQZbM5LUXRw9TaQTAfeMEnGk89y2p2XJKgeNxH https://100.66.0.3:8881
...
... other output omitted ...
...
{
      "file_type": "LetheanGateway",
      "type": "http-proxy",
      "file_version": "1.1",
      "gateid": "free-http-proxy-tls",
      "providerid": "f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab",
      "revision": 1712410097,
      "ttl": 3600,
      "name": "HTTP proxy to access other Lethean instances",
      "description": "Used to access internal Lethean infrastructure",
      "price": {
        "per-day": 0
      },
      "internal": true,
      "http-proxy": {
        "host": "100.66.0.3",
        "port": 8887
      },
      "spaces": [
        "f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab.free"
      ]
    },
    {
      "file_type": "LetheanGateway",
      "type": "http-proxy",
      "file_version": "1.1",
      "gateid": "http-proxy-tls",
      "providerid": "f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab",
      "revision": 1712410097,
      "ttl": 3600,
      "name": "HTTP proxy to access Internet",
      "description": "Used to access Internet",
      "price": {
        "per-day": 100
      },
      "http-proxy": {
        "host": "100.66.0.3",
        "port": 8880
      },
      "spaces": [
        "f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab.internet"
      ]
    }
  ],
 "providers": [
    {
      "file_type": "LetheanProvider",
      "file_version": "1.1",
      "providerid": "f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab",
      "name": "Easy-provider-f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab",
      "description": "Easy-provider-f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab",
      "revision": 1712410097,
      "ttl": 3600,
      "ca": [
        "-----BEGIN CERTIFICATE-----\nMIIDrjCCApagAwIBAgIUAcY7OaGu3lYdNiep8bN8v8SyrMAwDQYJKoZIhvcNAQEL\nBQAwWTFXMFUGA1UEAwxORWFzeS1wcm92aWRlci1mNGMzMGNiMGYzYTkzZGRjNjcy\nOGQwMDNkYzgzYWUwOTZlYjQ0YzZkNmQ1YTIwNjYyMGFkMGU0YTA4Y2RlNGFiMB4X\nDTI0MDQwNTEzMjc1NloXDTI2MDcxMDEzMjc1NlowWTFXMFUGA1UEAwxORWFzeS1w\ncm92aWRlci1mNGMzMGNiMGYzYTkzZGRjNjcyOGQwMDNkYzgzYWUwOTZlYjQ0YzZk\nNmQ1YTIwNjYyMGFkMGU0YTA4Y2RlNGFiMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A\nMIIBCgKCAQEAuRImHRxO+sNQbnrpTb4sqBT4aUvKIjQmbe2BUdqmpLddU4V+drg8\nd6c/W984Mr3vQrVLDj4Lhe8fnyWfMosZKA9WqZ1dQ/gl28ZBAzra8t6qw38NKn+h\nwqhE/sH0dQ2sdn5PDQCe6Y1ddE6VHqbPD2ycvfMwiwTFUPZzyOwZPZ5+Np2N3PBI\nJ5yCF71MuoOdRklCV6nzZYMLoA+EEv9grDZL/ykB94wtEjnsHIrtxSUFR3dmCf94\nsLwIh4+fA3R4hE5+igPedczEFfvvdU9FYuGicMrHUpTBvkZJ0HVK8/XDu6B3iRv8\n5gInQicTT/xJR6BkIBlrx1rR1LKLaIl9UwIDAQABo24wbDBZBgNVHREEUjBQgk5F\nYXN5LXByb3ZpZGVyLWY0YzMwY2IwZjNhOTNkZGM2NzI4ZDAwM2RjODNhZTA5NmVi\nNDRjNmQ2ZDVhMjA2NjIwYWQwZTRhMDhjZGU0YWIwDwYDVR0TAQH/BAUwAwEB/zAN\nBgkqhkiG9w0BAQsFAAOCAQEAiPBzcEQKxAtYa20vuQ2cmCi9SnQH0ilEJk0iyfbN\nKc5rKOgvu/ucnGTLhuYX8750R3h1YSYpzWqol22cRvheSHwP7tGWPEIX6CICgpNQ\nSVuH91otW/dzEIAKvXK41oRyFec+35xZYpJHP2EzpBUQh1DNtIejHKGKFbpOzjMf\ndWHVDwLMaTqxFXDwgR1AtUPz2Ochr6sDdct/fFyegpVJve5NKtq2X7QF2g+NBLF7\nzXCQAMnIj8CSmOs78ZjUVZzmweJgcBElatwywOTC9h6/GlSasBm4gWK7yDnW+VKf\nZUQ41dWGS3D7U7PhM4NQ6os8Z2Bvmhvp2lvBmPk787jaYw==\n-----END CERTIFICATE-----\n"
      ],
      "wallet": "iz652MfZBxjC8AVpSHHnby8RsHpqox2SMBF7AWGPtnQU8DKmEdoL6k161TxwQZbM5LUXRw9TaQTAfeMEnGk89y2p2XJKgeNxH",
      "manager-url": "https://100.66.0.3:8881",
      "spaces": [
        "free"
      ]
    }
  ],
  "signatures": []
}

After "Easy-provider" completes, I observed the local interface IP address of lvpnc_30925fcc interface being 100.66.0.4,

$ docker exec -ti letheannode ifconfig
...
... other output omitted ...
...
lvpnc_30925fcc: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 100.66.0.4  netmask 255.255.0.0  destination 100.66.0.4
        inet6 fc00::66:0:0:b7d9:d2b9  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 110  bytes 43864 (42.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 132  bytes 24040 (23.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I've then re-setup the vdp manager url with the expected interface IP which helped workaround the ability to talk talking with the local vdp.

docker exec -ti letheannode /entrypoint.sh lmgmt generate-vdp Easy-provider-f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab free 100.66.0.4 iz652MfZBxjC8AVpSHHnby8RsHpqox2SMBF7AWGPtnQU8DKmEdoL6k161TxwQZbM5LUXRw9TaQTAfeMEnGk89y2p2XJKgeNxH https://100.66.0.4:8881

Checking via show-vdp did show the correct updates in the output and i could access the vdp successfully inside the container. A push-vdp also now reflects the correction.

---

The issue above however is possibly a non-issue for general external users only reading the configuration of the vdp from outside of the container, since docker will pass the inbound session to any adapter in the container having the open listening port open since it's not explicitly locked down. Through testing if using a public IP or FQDN for the vdp manager and accessing the VDP manager from outside the container on tcp port 8881, this appears to work.

docker exec -ti letheannode /entrypoint.sh lmgmt generate-vdp Easy-provider-f4c30cb0f3a93ddc6728d003dc83ae096eb44c6d6d5a206620ad0e4a08cde4ab free 100.66.0.4 iz652MfZBxjC8AVpSHHnby8RsHpqox2SMBF7AWGPtnQU8DKmEdoL6k161TxwQZbM5LUXRw9TaQTAfeMEnGk89y2p2XJKgeNxH https://<ip-or-domain-name-resolving-to-lethean-node>:8881