Issue with cloudflared tunnel run --token <token_value> in Managed CF Tunnels

[lu4t]

First of all, congratulations on creating such an excellent library! 🎉

I have a suggestion/issue: It doesn't seem to handle starting a CF managed tunnel properly with the command:

cloudflared tunnel run --token <token_value>

I’ve looked into running it as a service but haven’t found a way to pass the token parameter for startup. Am I missing something, or is there an issue with the token handling?

Any guidance or clarification would be greatly appreciated!

Thank you!

[JacobLinCool]

Hi, can you share your output or error?

[lu4t]

It doesn't actually return any errors, and the tunnel is established correctly. Since this is a managed tunnel, the ingress rules are managed through Cloudflare's web interface as expected, and everything works fine.

The issue is that I need to access the properties of tunnelProcess (see code below), but the library doesn't allow parsing the response when the tunnel being established is not a quick tunnel. For managed tunnels, Cloudflare doesn't assign an ephemeral URL, so the value of the url property will not exist. Instead, the ingress configuration is returned (which is equivalent to the config.yaml file created when the tunnel is installed as a service). See the ingress returned on the log too.

Here is the startup function I'm using:

    
        async function startTunnel() {

            try {
                node.status({ fill: "yellow", shape: "dot", text: "starting tunnel..." });
        
                // Obtén el valor del token desde el nodo de configuración
                const configNode = RED.nodes.getNode(config.token); // Asumiendo que `config` está asociado al nodo de configuración
                const token = configNode ? configNode.token : "";

                node.log(`config: ${JSON.stringify(configNode)}`);
                node.log(`token: ${token}`);
        
                // Configura los argumentos de la conexión en función del valor del token

                
                const tunnelArgs = token === "test"
                    ? { "--hello-world": null }
                    : token === ""
                        ? { "--url": "http://localhost:1880" }
                        : { "run": null, "--token": token }; // Nuevo caso para manejar tokens válidos
        

                // Si `tunnelArgs` está vacío, lanza una advertencia
                if (Object.keys(tunnelArgs).length === 0) {
                    throw new Error(`Invalid token: ${token}`);
                }
        
                const { url, connections, child, stop } = await tunnel(tunnelArgs);


                // Procesar stderr del túnel
                child.stderr.on("data", (data) => {
                    const str = data.toString();
                    node.warn(`Log de error del túnel: ${str}`);
                });


                node.log('Antes de inicializar tunnelProcess...');

                tunnelProcess = {
                    url: await url,
                    connections,
                    child,
                    stop
                };

                node.log(`Después de inicializar tunnelProcess: ${JSON.stringify(tunnelProcess)}`);
                
                
                node.log(`Tunnel process inicializado: ${JSON.stringify(tunnelProcess, (key, value) =>
                    typeof value === "object" && value !== null ? "[Object]" : value
                )}`);


                const globalContext = node.context().global;
                let tunelList = globalContext.get("tunelList") || [];


                tunelList = tunelList.filter(nodeInfo => nodeInfo.id !== node.id); 
                tunelList.push({
                    id: node.id,
                    url: tunnelProcess.url,
                    status: "active"
                });

                globalContext.set("tunelList", tunelList); 


                globalContext.set(`tunnelProcess_${node.id}`, tunnelProcess);
                        
                const conns = await Promise.all(connections);
        
                node.status({ fill: "green", shape: "dot", text: "tunnel active" });
                node.log(`Tunnel started. URL: ${tunnelProcess.url}`);
                node.send({ payload: { url: tunnelProcess.url, connections: conns } });
        
            } catch (err) {
                // node.status({ fill: "red", shape: "ring", text: "error starting tunnel" });
                node.error(`Error starting tunnel: ${err.message}`);
            }
        }

This is the log returned when you enter a valid token in the code above.

9 Dec 00:38:42 - [info] [cloudflared:29ee915efc9c73d0] token: eyJhIjoi...TQyNjkwOW...iOThhMjYiLCJ0IjoiNWU...1MjctMDBkMGQ5N2RmM2ZlIiwicyI6...ORGxtWmprMSJ9
9 Dec 00:38:42 - [info] [cloudflared:29ee915efc9c73d0] Antes de inicializar tunnelProcess...
9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Starting tunnel tunnelID=5e8c00b1-45e4-8527-00d0d97df3fe

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Version 2024.11.1 (Checksum 55d789465955ccfffcd61ba72807a2a4495002f7d9b7cc5eadcaa1f93c279d25)
2024-12-09T00:38:42Z INF GOOS: linux, GOVersion: go1.22.5, GoArch: amd64
2024-12-09T00:38:42Z INF Settings: map[token:*****]

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Autoupdate frequency is set autoupdateFreq=86400000

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Generated Connector ID: 325ea0aa-5c98-ac73-6ccbb7eaed3a

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Initial protocol quic

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF ICMP proxy will use 172.17.0.2 as source for IPv4

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF ICMP proxy will use ::1 in zone lo as source for IPv6

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Starting metrics server on 127.0.0.1:46611/metrics

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024/12/09 00:38:42 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.

9 Dec 00:38:42 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:42Z INF Registered tunnel connection connIndex=0 connection=422ff6d3-f186-9060-c7d0ea6633d2 event=0 ip=198.41.192.27 location=mad01 protocol=quic

9 Dec 00:38:43 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:43Z INF Registered tunnel connection connIndex=1 connection=df8dbd2f-4dc7-a3dc-6dc960cd7539 event=0 ip=198.41.200.53 location=mad04 protocol=quic

9 Dec 00:38:44 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:44Z INF Registered tunnel connection connIndex=2 connection=942f5402-92f7-8969-a00e2ccc6cfb event=0 ip=198.41.200.13 location=mad03 protocol=quic

9 Dec 00:38:44 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:44Z INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"host.mydomain.com\", \"service\":\"http://localhost:1880\"}, {\"service\":\"http_status:404\"}], \"warp-routing\":{\"enabled\":false}}" version=1

9 Dec 00:38:45 - [warn] [cloudflared:29ee915efc9c73d0] Log de error del túnel: 2024-12-09T00:38:45Z INF Registered tunnel connection connIndex=3 connection=0a670d23-5051-9ffa-38ba17148282 event=0 ip=198.41.192.107 location=mad02 protocol=quic

If you need a valid token for your tests, and you don't have one, happy to share one.

[lu4t]

Hello @JacobLinCool , have you had a chance to take a look at the logs?
I was thinking that perhaps the ideal solution would be for the library to also return the "ingress" property, where the response sent by Cloudflare when a managed tunnel is deployed could be parsed. The idea is to follow the same design principle used with free tunnels, where the access URL content is retrieved and parsed. What do you think?

[JacobLinCool]

I'm not really sure what you mean by "ingress" here. Did you mean streaming out the raw stdout/stderr to downstream library users? I think it's a good idea.

I just tested it with the CLI (using cloudflared 2024.12.1 under the hood), and it seems to work (cloudflared tunnel run --token <token_value> works). So, I think you are referring to the library part, not the CLI part. Is that correct?

[lu4t]

Indeed @JacobLinCool , the CLI works correctly, and the tunnel is established and functions as expected.

It is the library portion that needs to be modified (expanded in functionality). Let me try to explain what I mean:

Currently, the library takes stdout and looks for a string containing a structure like:

2024-12-09T00:36:30Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2024-12-09T00:36:30Z INF |  https://chat-tiger-gate-suburban.trycloudflare.com

When it detects (using a regex) the string starting with "https", like https://chat-tiger-gate-suburban.trycloudflare.com on the example, it assigns this value to the url property (child.url).

However, when the tunnel is established using the command: cloudflared tunnel run --token <token_value> the format of the stdout to search and parse looks like this:

9 Dec 00:38:44 - [warn] [cloudflared:29ee915efc9c73d0] Tunnel error log: 2024-12-09T00:38:44Z INF Updated to new configuration config="{\"ingress\":[{\"hostname\":\"host.TLD.com\", \"service\":\"http://localhost:1880\"}, {\"service\":\"http_status:404\"}], \"warp-routing\":{\"enabled\":false}}" version=1

From this line, the most relevant value is the array encapsulated within the property called "ingress". From this value, the relevant details about the established tunnel can be extracted (parsed), namely:

• the public DNS providing access to the tunnel and
• the services accessible through the tunnel, which are exposed via Cloudflare's CDN.

Ideally, there should be a property (perhaps named ingress, or reusing the existing url property) that contains this array. In the example above, it would have the value:

[{\"hostname\":\"host.TLD.com\", \"service\":\"http://localhost:1880\"}, {\"service\":\"http_status:404\"}]

With this change the library would be compatible with any kind of tunnel. I hope now it's clear what I meant.

---

I edit to add something I just realized: On the screenshot you sent, you do not see an entry on the log containing the "ingress" definition, cause you are using a config.yml file locally. You will only get it if the config of the tunnel is managed (from the Cloudflare web UI).
Nevertheless, in both cases, the library is not aware that the tunnel has started, cause the library child process is expecting to complete the parsing and return the url property.

[JacobLinCool]

Oh yes, I finally figured it out!

I’ve created a new PR #28 that parses the configuration from the output. You can check it out here and let me know if it fits your use cases. You may be interested in examples/events.mjs.

[lu4t]

Awesome!... will try it and get back with findings!!!

Thanks!

[lu4t]

Works great!