I've been doing this career for 35+ years, I "quite understand" it just fine. You might notice the "aws" in my username. Phonetically, it's "into AWS" But, some info:
There is this routing thing called "anycast" which advertises a BGP route from multiple "points of presence" around the world. It's been used for decades with things like DNS servers. The famous 4.2.2.2 and 8.8.8.8 DNS servers don't just live in a single datacenter. There are servers all over the place with those IP's. the routers in those datacenters are set to "advertise" that subnet to the world. When someone in austin connects to "8.8.8.8" the traffic goes to the "closest BGP route" to them. When someone in hong kong connects, it goes to the POP that is closest to them. This is the old school legacy way of doing it, where the anycasted address has a physical server at the POP.
Also, by "closest to them", I mean.. in terms of internet latency or router hops. Not necessarily the geographically closest point.
Now, add cloud providers to the mix, who often run their own private networks. I'll use amazon as an example.
I spin up a server in whatever region I choose. Lets say I choose germany. So, I spin up an ec2 instance in germany. I add the capability to anycast to it, for roughly $20 a month using an offering they have called "global accelerator" which does the same as above, except this time.. I don't need a physical server at each POP. The routes are advertised from a multitude of amazon edge locations (seattle, miami, pheonix, atlanta, etc etc). so the traffic coming from YOUR device, would hit the nearest POP. But in reality, thats just the "on-ramp" for the traffic to hit amazons network. Once it's on their network, it can 100% go to china without you ever being any wiser.
And this only uses a simple routing technique. It's actually pretty trivial to do, AND doesn't take into account any of the reverse proxy options that anyone in the world has available to them (cloudfront, fastly, cloudflare, etc) that simply takes the traffic and "proxies" it to whatever I want on the backend. So once again, you connect to "miami" but on the backend, it's just reverse proxied to china.
In the modern era of cloud computing, "geo detection" of outbound L7 traffic is (or rather, can be) a farce. Anyone that *wants* to fool you into thinking you are connecting to a local server, can do it at minimal effort or cost.
*Edit* I love a challenge. I set this up in about 10 minutes.
I've created a webserver on AWS. hostname is "
http://diysolarforum.n2aws.com"
Feel free to browse to it, and let me know where your L7 filtering thinks it's located. Hint: it's just using anycast, no reverse proxy or other smoke and mirrors. It's simply routing. What city or country do you think it's located in?
And finally.. this capability/technology has a *ton* of practical purposes. it's not necessarily intended for this kind of "avoid firewalls blocking traffic to certain countries" stuff we're discussing here, but it IS one of the things it's excellent at as a side-product of using it. There are numerous legitimate reasons one might use this technology without a nefarious intent.
.
