Speaking as someone with over 20 years of networking experience, to me, this sounds like a routing problem on 3bb's end actually. If they're using an aggregated network, it's likely that they are using dynamic routing which would mean that depending on the time of day and network loads, they attempt to route the connection through a path that is problematic only some of the time, as is the nature of dynamic routing, which is more common to aggregated networks. I would be curious to see the traceroute as far as it will go (to Hyperfilter IIRC) on a day when it is working and a day when it is not to see the difference in the route that it tries to take. Chances are that it may not be directly on 3bb's end, but rather, something to do with blockades being put in place by one of their third party upstream vendors that provides the actual route through the internet. If this is the case, this would explain why 3bb is scratching their heads trying to figure it out, as the problem would be with the routing through only some of the network paths that they use. The sad part about dynamic routing is that depending on a number of factors, the route will change from one time of the day to the next. I suspect that the problem very well may be that they are trying to route though another country at times, which may run into blockades placed by foreign government.
The other possibility (although unlikely) is that the problem lies within the DNS servers, which do not actively respond properly as they should, although from the sounds of it, this is far less likely. Part of why I suspect that it may be the routing is based on issues that I have seen pop up with my ISP from time to time. For example, there was recently a problem with one of the routes that my ISP (TekSavvy) was using to get to YouTube. The connection would pass successfully from my modem, through their gateway, through the Toronto Internet Exchange (Packetflow I believe they refer to it as), then would bounce through Hurricane Electric's network grid. The problem came in however that when trying to send the traffic through one particular route through HE (Detroit I believe it was), the packet would make it into the first system, but then would frequently drop between the first hop in HE's system in Detroit and one of the two following relays in that route. Once TekSavvy changed the route to run through Chicago instead, the problem cleared up. The interesting part is that this problem was not limited only to YouTube, but also to other streaming sites, some of which were located in Canada. So… Even though the connection was going from Canada to Canada, at some point in the middle of the route, the connection takes a few bounces through the United States... So.... If the same kind of thing is happening with 3bb, it is possible that the problem may be with the dynamic routing trying to route requests at times through a country which has a blockade on this type of internet traffic.
It's a very high-tech explanation, but I'm almost certain that this will be the key to what the so-called "professionals" are overlooking. That is of course, assuming that they are actually being retarded and overlooking the possibility of routing through a foreign territory in some of their dynamic routes, rather than just not bothering to mention it or check for it because it's a "gay" thing, so they cannot be bothered. I don't know how vast homophobia is in that part of the world, so it's hard to say whether they're overlooking it, or they're just assuming it's not on their end because the connection leaves their network, so they cannot be bothered to look into it in more detail. Nevertheless, the traceroutes on a day when it works and on a day when it doesn't work compared to one another will surely tell whether or not this is the case. I would strongly suspect that their "technicians" are defined as the "barely trained" technicians as referred to in this video are just blindly pointing the finger at GT.ru for the problem because they're not looking past their network. They're likely only looking at the traffic as it passes through the part of the network that is their own domain, ignoring the fact that problems may arise in the routing past their network, but before the destination.
Perhaps this may provide the answer to your problem? If the routing is the case, this also explains why the connection works just fine through a VPN, as a VPN will force all of your traffic to be routed through the VPN tunnel to get out to the internet, thereby forcing it to take a route other than the one allocated by your ISP by bouncing the traffic off of the VPN instead of taking your ISP's default route.
