--link fails possibly because of the binding address

[aghasemi]

Hello,
I tried to run code-server with the --link option, and it ran without printing any errors into console, pointing me to some https://****.cdr.co/ address. However, opening that address did not work for me, with the error message "cannot connect to instance.." printed on the Browser screen. Still no error in the console.

I guess the failure to connect is because --link uses 127.0.0.1 as the binding address, whereas in the VPS I use, it must be 0.0.0.0, and that's how I manage to run code-server without --link.

Is there a way to tell --link to use 0.0.0.0 as the binding address and then some random port, instead of 127.0.0.1 and some random port? I have already set bind-addr to 0.0.0.0 in config.toml, but it is apparently ignored by --link.

Many thanks.

OS/Web Information

• Web Browser: Chrome 92
• Local OS: ChromeOS
• Remote OS: Ubuntu 20.04
• Remote Architecture: AMD Ryzen
• code-server --version: 3.11.1

Steps to Reproduce

1. Run code-server with --link on a server that needs the binding address to be 0.0.0.0 to be accessible outside

Expected

Access code-server via cdr.io proxy link

Actual

Code-server is not accessible via proxy link

Update: I looked into the source code and it seems that line 450 of the file cli.ts can do the trick. No?

[jsjoeio]

Can you use config.toml? If you can, that's news to me! Usually it's config.yaml. Did you try that already?

cc @code-asher

[aghasemi]

Yes, it is config.yaml. Sorry for my mistake.

I have set 0.0.0.0:39090 as my bind-addr, but these settings are randomized by --link, as printed on the screen, to 127.0.0.1:SomeRandmPort, where the IP makes the problem.

[jsjoeio]

It's too bad you can do something like 0.0.0.0:* but that wouldn't work. I'm not 100% sure how to address this but hopefully @code-asher can chime in. Guessing it won't be till next week though (company off-site this week).

[aghasemi]

Many thanks. Waiting for it. Honestly, I'm a bit surprised that I am the first one who has this issue.

[mtxweb]

I have had the same problem for a few days

[code-asher]

link (just for context link is a separate binary that ships with code-server) is not a traditional reverse proxy so it does not need to be exposed (it dials out to our cloud rather than having connections dial in). We override the host and port on code-server because we disable authentication (since link uses GitHub oauth and we don't want users needing to log in twice) and it would be sketchy to listen on 0.0.0.0 without authentication. Only link needs to be able to communicate with code-server and they're on the same machine so localhost works for that. Unfortunately we don't get much in the way of logs since the connection just fails without any additional information. For more context on how link works check out these issues: - #2704 - #2708 I think seeing code-server on localhost yet somehow "exposed" is very confusing. Maybe we should listen on a socket instead or skip the listening output altogether and say "established link to the cloud" or something like that. Documentation might also help. Link is currently undergoing a rewrite which I think has a good chance of resolving this issue.

[aghasemi]

Thanks. So there is no solution right now?

[code-asher]

It's possible that the issue you're running into is the same as #2734 which is ultimately caused by being in a different region from the cloud proxy (or server, not sure which). If that's the case the only known workaround is to use a VPN (the new version of link shouldn't have this region issue).

[aghasemi]

It can be. The server (I think) is in the US and I live in Switzerland. Really looking forward to the new version then. I appreciate if you announce it here. Any timeline?

[mtxweb]

If it helps, I also live in switzerland and the server is in germany

[code-asher]

I don't believe there's currently a timeline. I will make sure we announce the new version release here and in #2734.

[aghasemi]

Hi. Any news here?

[jsjoeio]

No news sadly :( Still waiting for the latest release on link which is done by another team. We'll update here with any news as it comes in! Sorry for the wait

[aghasemi]

Hi. May I ask please if there is a roadmap for fixing this?

[code-asher]

Unfortunately no, the link project looks to be shelved indefinitely. At this point I would recommend using something like Caddy to serve code-server.

[aghasemi]

Unfortunately no, the link project looks to be shelved indefinitely. At this point I would recommend using something like Caddy to serve code-server.

Many thanks. That's sad.

Any tutorial or guide about this caddy thing?

[code-asher]

We have a bit of documentation here: https://github.com/coder/code-server/blob/main/docs/guide.md#using-lets-encrypt-with-caddy Lemme know if you run into any trouble.

[code-asher]

Something like ngrok might also work. https://ngrok.com/

Or if you have SSH set up you could port forward through SSH https://github.com/coder/code-server/blob/main/docs/guide.md#port-forwarding-via-ssh

[aghasemi]

We have a bit of documentation here: https://github.com/coder/code-server/blob/main/docs/guide.md#using-lets-encrypt-with-caddy Lemme know if you run into any trouble.

Many thanks. Sorry for my naïvity, but do I need to do something in Let's Encrypt before going through these steps, or these steps are just all that is required?

[code-asher]

Yep, those are all the steps required. As long as you have a domain pointing to the right spot Caddy can set up Let's Encrypt for you.

[aghasemi]

It worked. Amazing. Many thanks.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.