This article is being updated.

The Russian internet is in a stalemate. Some foreign services are no longer reachable directly. Some left on their own, others were restricted by Roskomnadzor (Russia’s federal communications regulator, RKN). For years, users and businesses worked around this censorship with VPNs. Now VPNs are under pressure: the political regime blocks them, throttles them, and detects them by TSPU (Russia’s “technical means to counter threats” — deep-packet inspection infrastructure operated by ISPs under RKN’s direction). The workaround that once solved the problem has become part of it.

Against this backdrop, two initiatives for legal access to foreign resources have emerged at once.

The first initiative came from ISPs. On June 4, 2026, at the St. Petersburg International Economic Forum, Beeline CEO Sergei Anokhin told RBC that ISPs were consulting with the authorities on a mechanism to access services that were not blocked but unreachable without a VPN (including Netflix and AI platforms). Beeline opened access to several services, including Spotify, on Wednesday, June 10.

The second initiative came from the regulator. On June 8, the independent outlet The Bell reported that Roskomnadzor, at a closed meeting with IT companies, proposed creating a unified “GosVPN” (governmental VPN) for developers who have lost stable access to GitHub, PyPI, and other repositories.

At first glance, these ideas look like sensible responses to a real pain point. Both solutions, however, carry a built-in technical flaw: the more centralized the exit point, the easier it is for a foreign service to identify it as organized circumvention and block it across the board, for everyone at once. These initiatives also fail to address the root cause: many services remain inaccessible due to Russia’s own censorship.

Timeline

Date	What happened
April 2026	The “Otechestvenny Soft” (Domestic Software) association proposes creating a mediation body for a “balanced VPN blocking policy”: restrictions are hurting Russian developers (RBC).
May 2026	Surveillance of IP addresses and VPN blocking intensifies. Access to GitHub, Linux repositories, and, later, PyPI begins to degrade (see issues #7 and #8).
June 4, 2026	At the forum in Saint-Petersburg, Beeline CEO Sergei Anokhin tells RBC that ISPs are discussing access to Netflix, AI services, and other platforms without third-party VPNs. T2 (formerly Tele2) calls it a cross-industry initiative.
June 8, 2026	The Bell: at a closed meeting, Roskomnadzor proposes creating a unified “GosVPN” for developers and recommending they route traffic through it.
June 10, 2026	Beeline enables direct access to a range of foreign services for its subscribers.

The problem

There are actually two distinct inaccessibility problems, depending on why a given site is unreachable.

Consumer services. Netflix, foreign AI platforms, and various entertainment services. According to Beeline CEO Sergei Anokhin, some of these were never restricted by Roskomnadzor for non-compliance with Russian law. They simply stopped operating in Russia. So they are not blocked, but they cannot be accessed without a VPN. Common users bear the cost: those who need ChatGPT or Gemini for work or study, and those who just want to watch films or listen to music. Some content was pulled by rights holders, some was censored in Russia.

Development infrastructure. GitHub, PyPI, Linux repositories, Docker Hub, and development environments with cloud components. The stakes are higher here: builds break, dependencies fail to resolve, and releases slip. We covered this in detail in issue #8. The newspaper Kommersant (June, 2026) drew a direct line between developer problems and VPN traffic restrictions, noting that code repositories, libraries, and cloud-backed tools had all been caught in the crossfire.

The problem hits everyone at once: individual users, businesses, and the technical industry. That breadth is exactly what makes the idea of “proper” VPN access so appealing to both carriers and the regulator.

The Russian roots

One may read the whole story as “evil Western companies left and blocked everything.” Indeed, some services imposed restrictions for corporate or sanctions reasons. This is an external factor that Russia cannot influence as long as the war continues. What makes those services truly inaccessible is not their departure as such; it is that no circumvention tools remain.

The loop works like this. First, a service leaves Russia. Users start accessing it via VPNs. The state intensifies its fight against VPNs by blocking them via signature, demanding ISPs’ subscriber IP addresses, and fining ISPs for non-compliance. VPNs stop working reliably. The service becomes effectively unreachable again. And now, as a way out of this loop, a proposal has emerged: route through an authority-approved channel, which could be an ISP or the government.

Roskomnadzor began demanding subscriber IP addresses from more than 1,300 carriers, and 85 companies had already been fined for non-compliance. This data can be used, among other purposes, to determine whether a user is running a VPN. We also covered the goal of blocking 92% of circumvention tools by 2030 and documented the degradation of access to developer services.

In short, what is now being presented as “fixing the access problem” largely addresses the consequences of the policy that made resources inaccessible.

VPNs are losing their value

VPNs have been the default answer to accessibility problems. This role is eroding, and not only because of censorship.

• Circumvention channels are being actively filtered by signature, and ISPs have to identify and disconnect VPN users. What worked yesterday may not work today.
• Even a working VPN operates in “sometimes on, sometimes off” mode, and connection speeds to Western platforms are being throttled.
• The more people use VPNs, the harder it is for the government to respond, and the less predictable access becomes for everyone.

This is the gap that ISPs and RKN are moving into: they promise to make access to foreign services manageable.

Initiative # 1: ISPs and allow-lists

The ISP initiative works like this: an ISP gets permission from the authorities to open direct access to specific resources that currently require a VPN. Anokhin stressed that this was not about any federal list of permitted VPN services. The idea was simply to build a mechanism to access specific sites. He said the idea had “found support” and that several agencies had already discussed it. A representative of T2 (one of the major Russian ISPs)  confirmed that all carriers were working on it together.

Technically, Anokhin described this as an ISP’s own VPN service built directly into the subscription plan. No separate apps, just an option that activates without any user action. There is a pricing angle here as well. T-Mobile Russia CEO Vladimir Lyubimov told Vedomosti that only 20% of the users exceeded 15 GB of international mobile traffic per month. Consequently, these users may face additional charges for usage above that limit. Regaining access may come with a price tag.

RKN already maintains a registry of permitted VPN services, structured as a separate IP address allow-list controlled by the CMUPN (Center for Monitoring and Managing the Public Communications Network). By 2025, the list had reached 75,000 entries and continues to grow. RKN began collecting IP addresses and protocol data well before it moved aggressively against VPNs.

Initiative # 2: Roskomnadzor’s “GosVPN”

The second initiative is government-led and aimed at developers. According to The Bell, at the closed meeting, a RKN representative proposed creating a unified “GosVPN with a complex structure” and routing all the traffic through it. Temporary measures discussed at the same meeting included “maintaining operational coordination” with the agency and building a domestic open-source software repository.

The trigger was business complaints about disrupted access to foreign repositories amid the anti-VPN campaign. The Bell noted that the meeting was preliminary. No details about the state-backed VPN (or, as we call it, GosVPN) exist yet, and it is planned for discussion at future meetings. A source at one IT association said the idea has so far generated little enthusiasm in the industry. That matters: even those who are supposed to benefit from the service are lukewarm.

How both models work

Both schemes rest on the same principle: replace random, uncontrolled circumvention with managed, “legal” access. They differ in their target audience and in who holds the channel.

The first model (by ISPs) is an allow-list plus exit via the carrier’s own infrastructure: traffic to approved services is routed through a channel that the authorities can see. The governmental model is a single, centralized VPN under regulator control that developers should use.

It sounds reasonable: one predictable route instead of dozens of unstable VPNs. But that centralization also poses the main risk, as discussed below.

Pros

To be fair, the ideas have their merits.

• Legality. Users do not have to navigate constantly shifting restrictions. Access is officially permitted.
• Stability. A managed channel is, by design, more reliable than a “wild” VPN that may work today but not tomorrow.
• Seamlessness. An option built into the subscription requires no setup, removing a barrier for users who lack the skills to configure circumvention tools.
• Two problems, one move. Carriers cover consumer services; RKN covers development infrastructure.

Cons

A centralized exit is easy to spot and cut off

Foreign services know well how to detect organized geo-restriction circumvention.

• Streaming (Netflix and similar services). Accounts are not usually banned, but IP addresses that appear to be circumvention attempts are blocked. The service maintains a database of known bypass addresses and updates it constantly. An address that works today may be blacklisted tomorrow. Even ordinary residential IPs get caught. A single ISP exit is a large, highly visible pool of addresses. Once the service identifies it as a circumvention channel, access can drop for every subscriber at once.
• AI services (E.g., OpenAI). The approach here is stricter: the service may block the accounts themselves, including when it suspects VPN access from sanctioned jurisdictions. It has the right to deny access based on geography (“from Russia”), and in that case, a GosVPN won’t help.

The paradox is that the more centralized the channel, the more visible it becomes and the higher the probability that it gets blocked precisely for being organized circumvention.

A single point of failure and control

One channel is easier to block from outside and to filter or shut down from inside. There is also an ethical risk, which The Bell’s sources raised: privileged access for a part of the audience while all others stay restricted.

The problem does not get solved; it gets preserved

The root cause is Russia’s own censorship policy. A “proper” VPN does not solve it. It layers on top, turning access from a default right into a service dispensed through a controlled point.

Recommendations for developers

Developers deserve a separate look because the stakes are higher for them and the temptation to grab a “ready-made” solution is stronger.

The short answer: do not build mass carriers or governmental VPN tools into your workflows as a basement. Here is why.

• It is just another single external dependency. The whole point of resilient development is not to keep critical access tied to a single point that can be switched off. A GosVPN or carrier channel is exactly that kind of point (now under someone else’s control). If the route is changed, filtered, or restricted tomorrow, your build stops, and you can do nothing about it.
• Poor fit for automation. CI/CD runners, package managers, and container builds handle unstable or filtered channels poorly: timeouts, partial downloads, and broken caches. This is the same problem as with common VPNs, which we described in our analysis of developer resource access.
• Trust and metadata. All your traffic to repositories and services passes through a centralized channel. For teams working on sensitive projects, such as media organizations and NGOs, this means the path your code and dependencies take runs through supervised infrastructure. That is a serious operational risk.
• The industry itself is skeptical. The GosVPN idea has not generated enthusiasm even among IT associations. That is a signal not to migrate workflows onto it if the service appears.

What to do instead is the same as what we recommended in our GitHub analysis: build resilience rather than searching for a single “correct” workaround.

• Mirror critical repositories.
• Run a self-hosted Git platform (GitLab CE, Forgejo, Gitea).
• Maintain a local dependency cache for Python, Node.js, and container images.
• Do not tie your single point of access to one jurisdiction.

A mass GosVPN is acceptable at most as a one-time bridge (to pull down dependencies and immediately store them in your own mirror), but not as a base solution. If you develop VPN services, the more relevant reading for you is our material on IP address surveillance and the factors to consider in your protocol design.

Encryption and obfuscation

There is a specific technical problem that puts GosVPN in an uncomfortable position before it even launches. The technology obviously needs to be able to disguise itself, so that foreign services take as long as possible to detect it. But the moment serious obfuscation is on the table, two paths open up, and both are problematic.

If the goal is a properly obfuscated protocol in the spirit of XRAY/VLESS (one that hides that tunneling is happening at all), that means working with cryptography. But the problem is that cryptography in Russia is heavily regulated: such a solution would need FSB approval and certification, which can easily stretch the project over years. If obfuscation is simplified to avoid cryptographic regulation, the central exit point will be quickly detected and blocked (the same centralization problem discussed above).

Perspectives

Both initiatives are still early. The ISP version is being negotiated with agencies. GosVPN is in the preliminary meeting stage, with no details. The direction, however, is clear: the state and business are moving toward a model where internet access is organized through controlled points.

For common users, this may mean a convenient option in their subscription plan — paid, and with the risk that the service itself blocks it tomorrow. For developers, the conclusion is harder: relying on a centralized “approved” channel means trading one dependency for another, one that is even less under your control.

Resilience still comes from multiple independent access sources, not from finding the perfect workaround.

Update: June 10, 2026

What was once a conversation is now a product: Beeline launched a “white VPN” within its bee subscription plan on June 9. The issues we described above surfaced instantly.

On June 9, VimpelCom CEO Sergei Anokhin told RBC that Beeline had opened direct access for its subscribers to foreign services that had left Russia but had not been blocked by Roskomnadzor. This is the first practical implementation of the “white VPN” concept.

Launch specifics:

• Services included: Spotify, Netflix, Ticketmaster, Brawl Stars, and “a number of others.” The carrier has not published a complete list.
• Who gets access: only subscribers to the current bee plan. The newspaper Vedomosti notes that similar access previously existed on “Plan B” tariffs and has now been extended to the “bee” tariff.
• How it activates: automatically — no extra charge, no separate app, no manual configuration. According to press reports, it works primarily on smartphones.

What about other carriers?

Only Beeline has launched so far. At the time of this update, T2 (the former Russian part of Tele 2) confirmed participation in the cross-industry initiative but announced no launch of its own. MTS and MegaFon declined to comment — no public launches or customer notifications.

The problems that showed up immediately

The launch illustrated the weak points laid out in the main analysis above.

Access to the screen does not mean you can use the service. Experts surveyed by Forbes note that open access to Spotify or Netflix is largely meaningless if you cannot pay for a subscription with a Russian credit card. You can reach the login page; you cannot pay.

IP blocking is a real barrier. The Insider reports that Netflix deleted Russian accounts and blocked logins from Russian IP addresses some time ago. So, a user still needs a foreign account, something Beeline’s own website apparently warns about. In other words, “white VPN” delivers a route to the service but does not remove the barriers the service itself has put in place.

Tied to a specific plan. Access exists only within the paid bee subscription — exactly the “access as a service, not a default right” model.

For developers, nothing changes. The launch covers mass entertainment services, not development infrastructure (GitHub, PyPI). Our conclusion from the “What This Means for Developers” section stands: do not build your workflows around this kind of carrier channel.

This article is being updated.