Well i know that and i thought that I did not have to notice that.
You should only add the IP-Network of your wireguard tunnel and the Google ones ... or any other traffic you want to route through wireguard
1 Like
how much of a speed drop did you notice?
with some tweaks like BBR i've had my server able to stream multiple highest res 4k remuxes at once, without breaking a sweat.. i wonder if that would still be possible with the wireguard setup?
If you get an VPS which allows you to use at least 1Gbps you should not have that much of a speed drop.
As you only route the Google Traffic through wireguard the connection between Plex and client are not going through wireguard.
My throughput between my server and google is actually between 400 and 600mbps.
Although not mentioned, I thought he made use of the -bind flag for rclone to bind it to a vpn
alas 99% of my stuff is in the cloud...
is there any way to really benchmark your servers connection to google drive?
Does it matter as long as it works
Again, you are just routing the Google Traffic through wireguard! All the other traffic is NOT being routed to wireguard.
Just so: At the moment there are about 10 user simultaneously watching stuff via my Plex, most of them in direct play! No buffering, no timeouts so far.
Technically your Server is getting the data from the Drive and will forward it to the client.
Just to be clear: You donāt have to go with my suggested solution and I am not obliged to bring any evidence and benchmarkings for the solution. If you want to know if that is a way for you try it out and test it by yourself.
If you also start to experience 429 errors you have the choice between routing the traffic through another way or rent a server at another Hoster and move all your stuff.
And btw: I have also 99% of my stuff in the cloud (approx 250TB).
2 Likes
yes... and thank you : ) i really appreciate all the help/and this ultimate workaround : )
i have a feeling yer right and eventually i'll get the 429's again.. and i'll have to try this...
i just wish there was a way to really bench mark it...
i guess the answer would be if i could still stream several 80meg a sec 4k remuxes at the same time
: ) : (
i got that 429 on my windows vm too. my Debian VM (same host, same external IP) is still fine. i don't get it
i setup a 3ā¬/month VPS on netcup with wireguard and route that like this
1 Like
yea... that makes NO SENSE ahahaha...
i have to wonder if there is some other variable going on here....?
i've been rock solid for like 14 days now since i added the stuff to the hosts file.... confusing...
Too many variables to track, in my opinion it's exactly as @smoon described above - Google is placing automatic blocks on IP ranges that hit certain limits or thresholds, so its going to depend on the range your server is in and which range the "offenders" are in.
It's unfortunately (or fortunately, however you look at it) likely nothing you are personally doing.
Either somebody is seriously abusing Hetzner resources to perform attacks against Google or Google is seeing degradation in their network from the amount of traffic they receive from Hetzner and finally had to do something about it.
my linux VM got some Problems one week before. There i did that Hosts config thing and its working since then.
I'm curious how long this will continue to work
Just some words to my history with this: As I ran into this problem first almost more than a year ago I just disabled IPv6 and it was working fine again. The problem occured a few months later again and repeatedly some months later ... I changed the DNS back and forth, I edited my hosts file etc. pp., All of these solutions were doing the job, but since 2 weeks or so even these changes are doing nothing. ThatĀ“s why I set up the wireguard solution.
Correct!
Well, I think itĀ“s both of them which sums up. Hetzner is renting out thousands of Servers each month. There are at least possibly thousands of customers which are creating traffic from and to google. I know that they have quite a few customers which are using Google Drive there. Also they will have quite few "customers" which are abusing Google Services with or without there own knowledge.
Just take a look from Googles perspective: What would you do if there is Traffic from a specific IP-Range which donĀ“t want to have? Right, you would do the same thing!
1 Like
to be honest.... no actually...... i wouldn't "do the same thing"
i'd change the rules, put it in writing.... and make it clear what was acceptable and unacceptable use of the service.... not mysteriously block paying customers with no warning/admonition/clue : )
color me nuts... but i still say there are other variables at work here.
Yeah okay, I also wouldnĀ“t just block whole IP-Ranges, but Google does.
ThatĀ“s the problem with the Big ones ... they can do this and they donĀ“t give a damn thing if it is affecting others, innocent users as well. They just donĀ“t want to pay people who are sitting there and checking everything by hand. They are using an automated service which is using an algoryhtm to decide if the traffic thatĀ“s coming in is good or bad traffic.
I, and surely quite a few other users opened Tickets with the Google Service and almost all of them are closed with the same answer: "There is malicious Traffic from your network, thatĀ“s why we are blocking it. please contact your provider/hosting company" and Hetzner says "We canĀ“t do anything about it, itĀ“s Googles Task"....
In the end the honest users are the ones which are suffering and are forced to find another solution.
1 Like
I have been trying to use rclone -bind to bind rclone traffic to the local IP of my wireguard client tunnel. This way i could remove the static entries in my hosts file but I can't get it to work. When I remove the static allow IPs from my wireguard config it does not go over the tunnel
Thats correct. You need to tell wireguard itself which networks are being routed through it.
Yeah, but if i do an NS lookup I'm seeing some IPs for googleapis.com that are outside these 2 ranges
Which IP-Adresses do you mean?
If I query the Google DNS Servers (nsX.google.com) I get these results for IPv4:
root@srv01-de ~ # host -t A www.googleapis.com
www.googleapis.com has address 172.217.16.202
www.googleapis.com has address 142.250.184.234
www.googleapis.com has address 216.58.212.170
www.googleapis.com has address 172.217.18.106
www.googleapis.com has address 172.217.23.106
www.googleapis.com has address 216.58.212.138
www.googleapis.com has address 142.250.185.74
www.googleapis.com has address 142.250.185.106
www.googleapis.com has address 142.250.185.138
www.googleapis.com has address 142.250.185.170
www.googleapis.com has address 142.250.185.202
www.googleapis.com has address 142.250.185.234
www.googleapis.com has address 142.250.186.138
www.googleapis.com has address 142.250.186.42
www.googleapis.com has address 142.250.181.234
www.googleapis.com has address 142.250.186.106
All of these IP-Adresses except the 216 ones are within the following IP-Networks:
172.217.0.0/16
142.250.0.0/15
For the both 216.58 IP-Adresses you can add the following network to your AllowedIPs line:
216.58.192.0/19
It seems that Google itself added some new IP-Adresses to the DNS Roundrobin entry for www. I just added them to my wireguard config
1 Like
Yeah was the 216.58.192.0/19 ones. I'm now getting much faster responses using DNS responses using Cloudflare DNS without these static entries in the hosts file. 12ms now when I was seeing 130ms when the VPN tunnel itself is 8.3ms
root@Ubuntu-2204-jammy-amd64-base ~ # traceroute www.googleapis.com
traceroute to www.googleapis.com (142.250.184.202), 30 hops max, 60 byte packets
1 xx.xx.xx.xx (xx.xx.xx.xx) 8.381 ms 8.383 ms 8.333 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * 142.250.173.56 (142.250.173.56) 11.887 ms 142.250.171.76 (142.250.171.76) 11.770 ms
8 * * *
9 142.251.64.185 (142.251.64.185) 11.748 ms * *
10 * 142.251.64.187 (142.251.64.187) 11.604 ms *
11 * fra24s11-in-f10.1e100.net (142.250.184.202) 11.634 ms *