why IP addresses from zone europe-west1-b are detected as being located in US instead of Europe by maxmind ?
Thanks
At this link, Gary Ling from Google posted:
"We are aware of this issue that (almost) all Google IP addresses are SWIP'ed to be Mountain View, CA. And at Google, it's not uncommon to remap a block of IPs from one location to another, especially given the elasticity of IP addresses for the Cloud. Too bad that many of external Geo IP services solely depend on SWIP database"
So your instance will be running in the geographical zone you select.
You can also read this discussion group for more information on this topic
Related
I have this question on my mind for a very long time. Why should I buy a domain? If I don't buy a domain, will I face legal Issues? Even if I buy a domain, where does my website name gets registered? Why can't I keep my domain name forever? Does popular websites like Google, Facebook too buy their domains every year? If yes, from who?
Let us assume that I have all facilities to host my website of my own, like 24/7 server, etc., Even after that should I have to buy a domain?
Could anyone help me in solving my doubt?
Referring to this incident described in Google paid this much to the guy who briefly owned Google.com, apparently, yes, companies do pay for their domains and may loose it.
If you've a hosting facility, you will need to reserve a public static IP address from an ISP and pay for it, at this point people can reach your website by typing in its IP, as you can reach Google through http://216.58.198.78
Registering a domain name is a process described in Domain Name Registration Process | ICANN and it is not available to public.
And here is a good read: Can you register a domain name directly with ICANN instead of through a middleman?
The short answer is yes. You need to buy it if anyone else that you should be able to reach your server via that address. DNS (Domain Name System) is the thing that translates a name (e.g. "www.google.com") to an IP address, which your computer connects to.
I would recommend trying do find a Domain Name Registrar for your domain (there are several per top-level domain, i.e. .com, .org, .no, .in, etc), and read a bit about how it works.
Examples of registrars are https://godaddy.com, https://domains.google, and several thousands of others.
I'm using Betfair's (sport betting) API and have put together some cloud functions to be triggered on certain events.
However, it seems that despite choosing a european region, in which it's legal to gamble online, the IP address of the server running the functions is in the US, so Betfair block any API request coming from the cloud function.
Is there any way I can guarantee that it comes from a european IP?
I did see an old post regarding this but hoping there's now an actual solution to it.
Thanks in advance.
I have been running about 20 servers in Google Cloud Platform.
This month which is only 7days passed, I have charged $546.76 for the "Google Compute Network Internet Egress from APAC to China 2,471.65 GB" suddenly.
And it still has been increasing.
At first, I have NOT provided like webserver or any service to china as publish, most likely VM Instances work as cron or crawler server.
And also I have checked network "Egress", which means output I think, every our servers in Google Cloud Platform, but I couldn't find any output like so huge traffic 2,471.65 GB.
So this huge amount output traffic is very strange to me.
So I would like to know
1, What is this charged for traffic? Am I getting attack from china ?
2, How can I make sure which server to send many traffic to china ?
3, Do I have to pay for google full charge even if such an unexpected traffic fee ?
Thanks.
See my previous answer on this topic for details.
You're being charged because you're sending traffic to China, perhaps in response to requests that users in China are sending to your server. Whether it's an attack or not is up to you to figure out, based on your service's typical usage patterns, and more importantly, logs from your server.
If you don't want to send any traffic to China, set your firewall rules to drop such traffic rather than respond with 404 or other error page: remember, any response traffic counts as "egress" and charged at standard egress rates.
Yes, because Google provided you the service of sending traffic to China, hence, Google had already paid its fees to send this traffic on your behalf. If you want to dispute this charge, see the support site and follow the links for billing.
I recently created a GCE instance in the "europe-west" zone.
Its intended to run an application that connects off to an external webservice.
When trying to login to the webservice I get an error about restricted region.
It turns out the webservice does not accept login requests from US regions.
I checked and even though my instance is in the "europe-west" zone, its associated IP is being reported as US.
Is there anything I can do to get a proper region IP or is there any way around this?
May need to abandon GCE if the answer is no...
Thanks
Robert
Reposting the answer from Gary Ling, product manager for external networking:
Thank you for posting the email. We are aware of this issue that
(almost) all Google IP addresses are SWIP'ed to be Mountain View, CA.
And at Google, it's not uncommon to remap a block of IPs from one
location to another, especially given the elasticity of IP addresses
for the Cloud. Too bad that many of external Geo IP services solely
depend on SWIP database. While we are evaluating what we can do to
help our customers, your best bet in my opinion is contacting your
API provider and explore options they may offer now.
To be more explicit, there are several ways that a Geo IP provider might determine the location of an IP address. Most of these probably won't work well with a global cloud provider like GCP.
Associate the IP with the region of the allocating internet authority. In this case, GCE has addresses mostly allocated from ARIN, the American Internet authority. Once allocated to Google, these addresses can be used in any location by managing routing rules on Google's internal network.
Associate the IP with the address of the registering company. In that case, the official address associated with all GCP IPs is the Google Mountain View headquarters, even for addresses used in Europe or Asia.
Use network distance measurements to determine where a subnet is located. This method is more expensive, because it requires sending active pings from multiple locations around the globe; typically the address is associated with the closest measurement node. This is a more accurate method, but requires running many well-connected nodes and sending a lot of internet traffic to, at a minimum, each /24 on the internet.
All IP address from the Google Cloud will always originate to US, particularly Mountain View City, because it is linked to Google HQ which is located there. I would like you to know that all data and hardware for your instance are located on specific data centers across the globe, depending on the location that you have selected. You may refer to this link [1] for reference. However, Google Public DNS uses the anycast routing to direct the packets to the closest DNS server geographically, so if you are assigning an IP address for any instance, Google's network will be aware that the IP address is on that zone, even if the IP address was originally from Mountain View, California. See this link [2] [3] for a detailed explanation. The reason that you see your instance's IP address originate from US is because the entire IP block is owned by Google and the ARIN information lists the address for the entire block to Google's HQ in Mountain View.
[1] https://groups.google.com/forum/#!searchin/gce-discussion/ip$20in$20us%7Csort:relevance/gce-discussion/otD1c6E-wWI/cvEDCUAlBAAJ
[2] Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?
[3] https://groups.google.com/forum/#!searchin/gce-discussion/us$20ip%7Csort:relevance/gce-discussion/RjzyHRBRujg/Fd21YlmOpzEJ
I was just installing Ubuntu and noticed it was downloading updates from ca.archive.ubuntu.com. How did it know I was in Canada? As far as I'm aware an IP packet carries no information regarding physical (geographcial location) and there is no stipulation in the Ethernet standard saying anything about information regarding location.
So how do things such as geolocation work? For example this website tells you which country your IP address belongs to. Is it just a matter of looking up an IP address in a table? If so where does the data come from, it's not as if people actively signup to have their IP address associated with the building address?
how does IP address geolocation work, does it just lookup the IP from a table?
Yes, that's exactly how it works.
IP geolocation is nothing more complicated than a database lookup. IP addresses are assigned by IANA to regional governing entities who then assign (sell) them to ISPs, governments and corporations (IBM for example has a dedicated block of IP addresses for themselves because they got into the internet game very early on).
Based on this fact we can sort of figure out where an IP address is located. IANA themselves publish the block level allocations on their site: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml which is rendered beautifully in this XKCD comic: http://xkcd.com/195/.
As for the more detailed info like which city that IP address comes from, to get that information requires more data gathering. Some ISPs may tell you their assignment schemes, most dont. So most databases like whatismyipaddress.com painfully build theirs up by surveys (simply asking people where they are or via smartphone apps tapping into GPS), looking up whois databases (which may or may not lie) and careful guessing.
Yes, your IP carries a geolocation as well. I'm not sure that's the best way to describe it, as it doesn't really carry the information (I don't think?). This link gives a pretty good idea of the kind of details they can get from your ISP though:
http://whatismyipaddress.com/geolocation-accuracy
Of course all of that revealing information can be partially negated by using a proxy.