ZeroTierOne
ZeroTierOne copied to clipboard
Connection failed using "forceTcpRelay"
When I force to use TCP mode, the network is unreachable, but if I use UDP he is normal.
root@localhost:/var/lib/zerotier-one# zerotier-cli info
200 info **** 1.10.6 ONLINE
root@localhost:/var/lib/zerotier-one# ping 11.2.0.11
PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data.
From 11.2.0.12 icmp_seq=1 Destination Host Unreachable
From 11.2.0.12 icmp_seq=2 Destination Host Unreachable
From 11.2.0.12 icmp_seq=3 Destination Host Unreachable
^C
— 11.2.0.11 ping statistics —
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 3
root@localhost:/var/lib/zerotier-one# mv local.conf local.conf.bak
root@localhost:/var/lib/zerotier-one# systemctl restart zerotier-one.service
root@localhost:/var/lib/zerotier-one# ping 11.2.0.11
PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data.
64 bytes from 11.2.0.11: icmp_seq=1 ttl=64 time=665 ms
64 bytes from 11.2.0.11: icmp_seq=3 ttl=64 time=324 ms
^C
— 11.2.0.11 ping statistics —
4 packets transmitted, 2 received, 50% packet loss, time 3029ms
rtt min/avg/max/mdev = 324.275/494.548/664.821/170.273 ms
root@localhost:/var/lib/zerotier-one# cat local.conf.bak
{
"settings": {
"forceTcpRelay": true
}
}
Because ISP will block UDP from time to time, I need to let him work in TCP mode for a long time.
sometimes it takes a minute to start working. sometimes it doesn't work because the relays are overloaded, you're too far away, etc... you can try to run your own relay if you want https://github.com/zerotier/ZeroTierOne/tree/dev/tcp-proxy
sometimes it takes a minute to start working. sometimes it doesn't work because the relays are overloaded, you're too far away, etc... you can try to run your own relay if you want https://github.com/zerotier/ZeroTierOne/tree/dev/tcp-proxy
Can he authenticate by running 'TCP proxy' on his own?
When I force to use TCP mode, the network is unreachable, but if I use UDP he is normal.
root@localhost:/var/lib/zerotier-one# zerotier-cli info 200 info **** 1.10.6 ONLINE root@localhost:/var/lib/zerotier-one# ping 11.2.0.11 PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data. From 11.2.0.12 icmp_seq=1 Destination Host Unreachable From 11.2.0.12 icmp_seq=2 Destination Host Unreachable From 11.2.0.12 icmp_seq=3 Destination Host Unreachable ^C — 11.2.0.11 ping statistics — 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms pipe 3 root@localhost:/var/lib/zerotier-one# mv local.conf local.conf.bak root@localhost:/var/lib/zerotier-one# systemctl restart zerotier-one.service root@localhost:/var/lib/zerotier-one# ping 11.2.0.11 PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data. 64 bytes from 11.2.0.11: icmp_seq=1 ttl=64 time=665 ms 64 bytes from 11.2.0.11: icmp_seq=3 ttl=64 time=324 ms ^C — 11.2.0.11 ping statistics — 4 packets transmitted, 2 received, 50% packet loss, time 3029ms rtt min/avg/max/mdev = 324.275/494.548/664.821/170.273 ms root@localhost:/var/lib/zerotier-one# cat local.conf.bak { "settings": { "forceTcpRelay": true } }
Because ISP will block UDP from time to time, I need to let him work in TCP mode for a long time.
Hi, have you figure out the solution? I'm facing the same problem now.
When I force to use TCP mode, the network is unreachable, but if I use UDP he is normal.
root@localhost:/var/lib/zerotier-one# zerotier-cli info 200 info **** 1.10.6 ONLINE root@localhost:/var/lib/zerotier-one# ping 11.2.0.11 PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data. From 11.2.0.12 icmp_seq=1 Destination Host Unreachable From 11.2.0.12 icmp_seq=2 Destination Host Unreachable From 11.2.0.12 icmp_seq=3 Destination Host Unreachable ^C — 11.2.0.11 ping statistics — 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms pipe 3 root@localhost:/var/lib/zerotier-one# mv local.conf local.conf.bak root@localhost:/var/lib/zerotier-one# systemctl restart zerotier-one.service root@localhost:/var/lib/zerotier-one# ping 11.2.0.11 PING 11.2.0.11 (11.2.0.11) 56(84) bytes of data. 64 bytes from 11.2.0.11: icmp_seq=1 ttl=64 time=665 ms 64 bytes from 11.2.0.11: icmp_seq=3 ttl=64 time=324 ms ^C — 11.2.0.11 ping statistics — 4 packets transmitted, 2 received, 50% packet loss, time 3029ms rtt min/avg/max/mdev = 324.275/494.548/664.821/170.273 ms root@localhost:/var/lib/zerotier-one# cat local.conf.bak { "settings": { "forceTcpRelay": true } }
Because ISP will block UDP from time to time, I need to let him work in TCP mode for a long time.
Hi, have you figure out the solution? I'm facing the same problem now.
My current approach is to use zerotier+tinc+ospf to automatically switch. Under normal circumstances, I use the zerotier network because it has a good control plane. When encountering problems, I use the cost value of ospf to switch to the tcp of tinc Temporary work in mode.
I think you need to deploy the tcp-proxy service yourself
{
"settings": {
"tcpFallbackRelay": "${your tcp-proxy server ip}/443",
"forceTcpRelay": true
}
}
The default tcp relay is at 204.80.128.1/443 may be unavailable
my config:
Can be referenced: https://github.com/zerotier/ZeroTierOne/blob/adfbbc3fb00becc578afc0645c60b1de3d84bb4c/tcp-proxy/README.md
tcp-proxy
tcp-proxy
Can TCP proxy be used as a backup? Use UDP first when UDP is available, and switch to TCP mode when UDP is unavailable?
tcp-proxy
Can TCP proxy be used as a backup? Use UDP first when UDP is available, and switch to TCP mode when UDP is unavailable?
The default setting is udp first , tcp relay as backup("allowTcpFallbackRelay": true ,"forceTcpRelay": false,)
tcp-proxy
Can TCP proxy be used as a backup? Use UDP first when UDP is available, and switch to TCP mode when UDP is unavailable?
The default setting is udp first , tcp relay as backup("allowTcpFallbackRelay": true ,"forceTcpRelay": false,)
I feel like your solution is working properly after testing. I would also like to ask if "tcpFallbackRelay" can set multiple addresses for redundancy?
tcp-proxy
Can TCP proxy be used as a backup? Use UDP first when UDP is available, and switch to TCP mode when UDP is unavailable?
The default setting is udp first , tcp relay as backup("allowTcpFallbackRelay": true ,"forceTcpRelay": false,)
I feel like your solution is working properly after testing. I would also like to ask if "tcpFallbackRelay" can set multiple addresses for redundancy?
I think "tcpFallbackRelay" cannot set multiple addresses, because the format of multiple addresses is not marked in the document. #1572 Configuring multiple self-built moon nodes may automatically select nodes with low latency, but I have not tested it. #1772