request a feature to change the endpoint ip:port

[Neomanbeta]

Sorry if i can't make myself clear, the thing is warp endpoint ips are heavily blocked in China, both ipv4 and ipv6, but it's still possible to find available endpoint ips to connect, as long as we can change it ourselves.
Like in this thread: ViRb3/wgcf#69

However, i cannot find a way to do it when deploying this project. Here is the log when I start the docker.

clientmethod: none

client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error
}

socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
}
[#] ip link add warp type wireguard
[#] wg setconf warp /dev/fd/63
[#] ip -4 address add 172.16.0.2/32 dev warp
[#] ip -6 address add 2606:4700:110:8e2d:31c0:2cfc:4dc5:518/128 dev warp
[#] ip link set mtu 1280 up dev warp
[#] resolvconf -a warp -m 0 -x
[#] wg set warp fwmark 51820
[#] ip -6 route add ::/0 dev warp table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev warp table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
[#] ip -4 rule add from 172.21.0.2/16 lookup main
[#] ip -6 rule add from fe80::42:acff:fe15:2/64 lookup main
curl: (6) Could not resolve host: www.cloudflare.com
Jun 27 16:19:19 (1719505159.034517) rws-cli[1]: info: Dante/server[1/1] v1.4.3 running
Jun 27 16:24:53 (1719505493.027793) rws-cli[353]: info: block(1): tcp/connect ]: 127.0.0.1.34906 127.0.0.1.9091: could not resolve hostname "www.cloudflare.com": Try again
Jun 27 16:24:53 (1719505493.028577) rws-cli[353]: info: block(1): tcp/accept ]: 127.0.0.1.34906 127.0.0.1.9091: request was not performed due to error: could not resolve hostname "www.cloudflare.com": Try again
Jun 27 16:27:37 (1719505657.243113) rws-cli[1]: info: sigterm(): exiting on signal 15
Jun 27 16:27:37 (1719505657.245301) rws-cli[1]: alert: mother[1/1]: shutting down

So, i would like to know, is it possible to implement a feature to manually change the endpoint (Endpoint = engage.cloudflareclient.com:2408) before the docker starts?

[Mon-ius]

Hi @Neomanbeta

That can be possible, if you can provide the minimal implementation about changing the warp endpoint. 🤗

[Neomanbeta]

Thank you for the reply, since I know absolutely nothing about docker or coding, I don't know whether I could provide any useful information you need, but i will try my best.
Normally I use a sing-box gui as a 3rd party WARP client. (sing-box is an universal proxy tool)
My warp json file for sing-box looks like this:
{
"interface_name": "WARP",
"local_address": [
"172.16.0.2/32",
"2606:4700:110:8193:ad15:aee3:14db:a32f/128"
],
"mtu": 1408,
"peer_public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
"private_key": "kLNEfMpFIqes3N4nLVeWfhw4QOABjIkYASXye+mzGng=",
"server": "engage.cloudflareclient.com",
"server_port": 2408,
"system_interface": false,
"tag": "proxy",
"type": "wireguard"
}

The part I need to change is "server": "engage.cloudflareclient.com" and "server_port": 2408, this is the part warp uses by default.
For example, change it to "server": "162.159.195.198" and "server_port": 1701, which is not blocked.
After changing it, I may connect to warp service.

[Mon-ius]

@Neomanbeta do you mean you can change the warp endpoint from singbox?

If so, can u provide further testing without singbox, but pure wireguard setup?

[Neomanbeta]

Not to change the warp endpint from sing-box, sing-box merely uses warp config that is written in its own format.
You can change warp endpoint in warp's official client.
Here is the example: https://blog.yourang.top/03-24/wcgf-ipyx/
It's in Chinese, but it's the best I could find.

This is the bat file content the article uses to change it, I translated a little bit for better understanding.

chcp 936
cls
@echo off & setlocal enabledelayedexpansion
set endpoint=162.159.192.1:2408
set /p endpoint=please input endpoint(default%endpoint%):
warp-cli tunnel endpoint reset
warp-cli tunnel endpoint set %endpoint%
echo current endpoint has been set to %endpoint%
pause

Also, in other 3rd party warp client, such as WGCF
https://github.com/ViRb3/wgcf
You can change it in wgcf-profile.conf

[Mon-ius]

@Neomanbeta cool.

I guess you want to change directly inside wgcf-profile.conf, this project is also based on it.

If so, can u provide the valid wgcf-profile.conf which contains the described given endpoint, e.g. ip and port.

And for clarity, it would be best, if you can provide the config file, before and after.

For this project, if u would like to set and test, just modify the produced file inside:

Docker-Warp-Socks/entrypoint.sh

Line 25 in 8edbfe0

wgcf register --accept-tos && wgcf update && wgcf generate && mv wgcf-profile.conf /opt

[Neomanbeta]

I would like to help you with that, but unfortunately I don't use wgcf myself, so I do not have the wgcf-profile.conf nor the config file you need.

EDITED: just realized you have given me the wgcf-profile.conf file location to modify myself, I will try then get back to you.
Thanks

[Mon-ius]

@Neomanbeta Once you test your proposal that works on the block area, can u submit a PR to this project?

I believe lots of people will benefit from that :)

[Neomanbeta]

It seems to be working right now. TBH I have no idea how.....Here is the test log. It took me days to setup my debian server with ipv6 and create a ipv6 bridge in docker, that was an extremely painful process, because only ipv6 endpoint ip works here.

root@D525-smallserver:~ curl --proxy socks5h://127.0.0.1:9091 https://www.cloudflare.com/cdn-cgi/trace
fl=464f121
h=www.cloudflare.com
ip=104.28.213.199
ts=1719813588.228
visit_scheme=https
uag=curl/7.88.1
colo=SJC
sliver=none
http=http/2
loc=CN
tls=TLSv1.3
sni=plaintext
warp=on
gateway=off
rbi=off
kex=X25519
root@D525-smallserver:~#

So it proves that change the endpoint ip&port is a working approach to solve the connection issue in places where engage.cloudflareclient.com:2048 cannot connect.

PS: As i said above, i know nothing about coding, so I don't know how to do a pull request, sorry.

[Neomanbeta]

I don't know where does it go wrong. It can pass the test inside the docker terminal;
/ # curl -f https://ip.sb/cdn-cgi/trace
fl=466f115
h=ip.sb
ip=104.28.213.199
ts=1719821100.357
visit_scheme=https
uag=curl/8.5.0
colo=SJC
sliver=none
http=http/2
loc=CN
tls=TLSv1.3
sni=plaintext
warp=on
gateway=off
rbi=off
kex=X25519
/ #

It can pass the test on the host machine as well:
root@D525-smallserver:~ curl --proxy socks5h://127.0.0.1:9091 https://ip.sb/cdn-cgi/trace
fl=466f115
h=ip.sb
ip=104.28.213.199
ts=1719821086.497
visit_scheme=https
uag=curl/7.88.1
colo=SJC
sliver=none
http=http/2
loc=CN
tls=TLSv1.3
sni=plaintext
warp=on
gateway=off
rbi=off
kex=X25519
root@D525-smallserver:~#

But I cannot connect from my local network, I've checked the iptables, everything is fine, docker automatically modified the iptables when deployed.
Even on the host machine, i cannot telnet the 9091 port by using Its ip address (192.168.1.240):
root@D525-smallserver:~ telnet 127.0.0.1 9091
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
exit
Connection closed by foreign host.
root@D525-smallserver:~# telnet 192.168.1.240 9091
Trying 192.168.1.240...
telnet: Unable to connect to remote host: Connection timed out

[Neomanbeta]

I think I've located the problem. Since I can only replace endpoint with an ipv6 address & port, I've created a docker bridge network with ipv6 support. By default this project creates a bridge network with only ipv4.
When i launch this docker in the ipv6 bridge network, during bootup it has an error:

warp_socks | 2024/07/01 23:01:18 Successfully generated WireGuard profile: wgcf-profile.conf
warp_socks | sed: unsupported command f
warp_socks | logoutput: stderr
warp_socks | internal: 0.0.0.0 port=9091
warp_socks | external: warp

I think this is the reason why access outside the host couldn't connect.

If I use the default ipv4 bridge that was created automatically, it doesn't have this problem, yet it does not support the ipv6 endpoint, which makes it useless.

[Mon-ius]

Hi, @Neomanbeta

Thanks for your test result. If I understand correctly, you are trying to modify the wireguard config file from wgcf generate.

It seems you meet a problem when handling ipv6 endpoint, do u try to replace the ipv4 endpoint?

[Neomanbeta]

Yes, I go straight to the folder where wgcf-profile.conf is located, then modify the endpoint ip & port and restart the docker.
Reason why I do not use ipv4 endpoint is because all ipv4 endpoint ips are blocked in my area, there is no ips left for me to test. However, in other regions where ipv4 endpoint ips are still available, it shouldn't be a problem.
From what I noticed, I might be wrong:
If I deploy the project using default, docker run or docker compose without touching anything, modifying the endpoint ip to a ipv6&port won't do anything, because the docker network is in ipv4 mode not with ipv6 enabled.
When deploying the project to a docker network with ipv6 enabled (i created in docker myself), after seeing the wgcf-profile.conf is generated in the logs, there will be an error as mentioned in my last post.
sed: unsupported command f
then the docker is stopped, not everytime but even it's not stopped, the end result is the same.
I think it's these commands cannot be excecute properly
sed -i "/[Interface]/a PostDown = ip -6 rule delete from ${_IPv6} lookup main" /opt/wgcf-profile.conf
sed -i "/[Interface]/a PostUp = ip -6 rule add from ${_IPv6} lookup main" /opt/wgcf-profile.conf
sed -i "/[Interface]/a PostDown = ip -4 rule delete from ${_IPv4} lookup main" /opt/wgcf-profile.conf
sed -i "/[Interface]/a PostUp = ip -4 rule add from ${_IPv4} lookup main" /opt/wgcf-profile.conf
I believe this causes something wrong in iptables, which blocks other devices from accessing 9091 port.

[Mon-ius]

@Neomanbeta thanks for your update.

As I know, the current issue is the ipv6 proxy part from container to host cannot be established.
Except this, do u test if the ipv6 based wireguard interface can be created? Which means u can enter the docker inside, then execute the curl to test.

Or if u can test on the host directly use same wireguard config with ipv6 endpoint specific?

[Neomanbeta]

I'm not sure what you mean, but if you mean even with the current issue at hand, can I use terminal to login the docker and execute curl? Then the answer is yes. I've already posted the curl test result from inside the docker in the previous post, the test passed.

/ # curl -f https://ip.sb/cdn-cgi/trace
fl=466f115
h=ip.sb
ip=104.28.213.199
ts=1719821100.357
visit_scheme=https
uag=curl/8.5.0
colo=SJC
sliver=none
http=http/2
loc=CN
tls=TLSv1.3
sni=plaintext
warp=on
gateway=off
rbi=off
kex=X25519
/ #

There is no need to test the wireguard config with ipv6 endpoint on the host, because I know it works. Because this is how I use WARP right now.

[Mon-ius]

@Neomanbeta

Reason why I do not use ipv4 endpoint is because all ipv4 endpoint ips are blocked in my area, there is no ips left for me to test.

So this issue has been solved now, right?

[Neomanbeta]

No, the problem is still there.
I think I've made you confused, so I will clarify the problem.
After modifying the wgcf-profile.conf, the docker can connect to the WARP service.
The socks works as well, see the test result above.
However, it only works for 127.0.0.1:9091. Due to the broken iptables, any access other than the loopback address is blocked.
For example, in order to use the proxy, I must access 192.168.1.240:9091 (this is the host machine's local address).
But it's blocked by the docker.
So even the WARP service is connected I can't use it.
On the host machine:
curl --proxy socks5h://127.0.0.1:9091 https://ip.sb/cdn-cgi/trace (success)
curl --proxy socks5h://192.168.1.240:9091 https://ip.sb/cdn-cgi/trace (failed)

[Mon-ius]

@Neomanbeta

After modifying the wgcf-profile.conf, the docker can connect to the WARP service.

ipv4 or ipv6?

Due to the broken iptables, any access other than the loopback address is blocked.

It was designed, not broken.

So even the WARP service is connected I can't use it.

In which case? ipv4 or ipv6? original hostname or modified endpoint?

[Neomanbeta]

1: ipv6, I cannot use ipv4 endpoint ips, they are all blocked.
2: OK, good to know
3: with modified ipv6 endpoint ip&port

[Mon-ius]

okay, can u abstract your operation into one command line without extra interaction, so I can add this feature as u first requested.

[Neomanbeta]

Say the ipv6 ip&port I want to change to is 2606:4700:d0::3ed0:74ce:7f61:70be:3476
the command would be:
sed -i 's|engage.cloudflareclient.com:2408|2606:4700:d0::3ed0:74ce:7f61:70be:3476|' /opt/wgcf-profile.conf
I'm not sure this is 100% correct, it seems alright.
But what about the connection problem. Are you gonna fix that as well?

[Mon-ius]

If the test on https://github.com/Mon-ius/Docker-Warp-Socks#13-test-and-verify works fine, it's not a problem.

If not, I will fix it.

[Neomanbeta]

I hope i'm getting this right.
Yes, the test curl -x "socks5h://127.0.0.1:9091" -fsSL "https://www.cloudflare.com/cdn-cgi/trace" is working fine. Normally, I can access this socks from other devices by using host machine's local ip address, in my case 192.168.1.240:9091, right?
But in this case, when the 127.0.0.1:9091 test passed on the host machine. No other devices from the local network can access the socks via 192.168.1.240:9091. Even on the host machine itself telnet 192.168.1.240 9091 failed.
This is the connection problem I'm talking about.

[Mon-ius]

I hope there are no issues for now.

Regarding the initial issue, I will find time to provide an extra option to replace the endpoint.

However, the problem you proposed, Accessing the current device from outside of the network, is beyond the current project's capabilities at this time.

Given that such an option may lead to abuse, we will release similar feature in version 3 once we find a proper way to limit such situations 🤗

[Neomanbeta]

OK, i see, thanks for the help.

[Mon-ius]

@Neomanbeta Hi, I got some time for apply your previous request to the mainstream. Before that I would like to perform more testing case for both IPV4 and IPV6 on your suggested area. I saw you first provide the singbox then the wireguard config, however, they dont work at current time, would u plz suggestion the new endpoint cases to replace engage.cloudflareclient.com 🤗

[peterweissbier]

@Neomanbeta wake up give us an update please

[Mon-ius]

close due to no response