Intermittent "We're sorry" error accessing Google via IPv6
I sometimes get the "We're sorry" or "unusual traffic" error
There is no suspicious activity whatsoever coming from my server. If there was malware on my server causing this, I would be reading a significant amount of IPv6 network activity on the Linode Manager, and I don't see any sign of trouble there. I have also been monitoring my server using htop and could not find any suspicious processes or activity. The firewall is configured to allow only HTTP and SSH traffic, and SSH is set up to only allow logins using public keys, not passwords. I have not seen any record of an unauthorized login into my server. A ClamAV scan finds no infected files.
Is Google blocking a range of IP addresses? I have read about Rackspace Cloud and other VPS users being affected by this issue. There's a good chance there are several Linodes running automated Google queries, probably to check search engine rankings. I would never be running these sorts of queries. To make it clear, only IPv6 is affected.
–DragonLord
7 Replies
According to this other post (
I've requested and configured an ip from a pool assigned to my linode, but unfortunately it has not resolved the problem. The pool appears to be forwarded to the original ip handed out using dhcp, so Google is still blocking the traffic.
I'm not sure how to resolve at this point. Disabling ipv6 works but that seems like the wrong tactic.
this thread
You'd need to add the relevant setting to sysctl.conf to ensure it was retained across a reboot. Also, disabling autoconf won't (I believe) remove an existing auto-configured address, but you'll be able to delete it manually and not have it come back. Or you can bounce the interface or reboot without picking it up.
Otherwise, you'll have to get into details of source address selection when multiple addresses of the same address family exist on the same interface (RFC3484 is the reference). You could deprecate an address (
But in this case, since the one you don't want is always the auto-configured one, disabling that seems simplest.
-- David
You can, of course, disable autoconfiguration and configure your main IP -- and route -- statically, but you can't remove it entirely.
@mnordhoff:
I don't think that will work, db3l. Your block of IPs is routed through your main IP – if you disable it, you'll lose IPv6 connectivity.
Hmm, are you sure? I just manually deleted the auto-configured address on one of my Linodes, added an address from my local 4096-address pool and it works fine. Though there are some differences between the 4096-address pool and a /56.
The 4096-address pools work through neighbor solicitation, so shouldn't have any dependency on other addresses. That's also why you can assign addresses from those pools arbitrarily to any Linode.
If you've also requested a /56 it does have to be explicitly routed through some other address. So if you chose an auto-configured address for that purpose then yes, it has to remain active, so avoiding it for outbound traffic probably requires the deprecation approach. But what I did for my /56, and what I think is more flexible, is to route the /56 through an address from the 4096-address pool. That way, your /56 will automatically route to whatever Linode you choose to assign that pool address and avoids any hardcoded dependency on a specific Linode.
– David
Note that my IP is crafted in a way that allows neighbor solicitation – I'm not sure if that helps source the address correctly. You can look here for more details
Also, if you're having a hard time troubleshooting where the packets are coming from you can use this:
# tcpdump -t -n -i eth0 -s 512 -vv ip6 or proto ipv6
I used it to inspect that packets being sent over the interface to Google were coming from the correct address. It works from the machine or if you're forwarding traffic (using a SOCKS tunnel for instance).
–
edit for tcpdump info
@brrak:
(…) Even though it says the /64 pool is "routed" to the original offending IP, Google doesn't seem to be blocking the traffic.
The next hop for the routed /64 is only used for inbound routing back to the /64 (e.g., how the public network reaches your Linode). Roughly, IP routing works with each step saying "I want to get to X, who (Y) should I send this to next" where X is the final address and Y is some intermediate address directly attached to the current box. That keeps happening until someone - your Linode in this case - says "no further, I'm X". So the route set up by Linode for your /64 is what lets that work for the very last hop (from Linode's routers to your personal Linode).
Anyway, that routing configuration is not something a destination site has any visibility to when they receive traffic from your Linode - they'll just see the source address selected for the traffic by your Linode.
– David