In a changing network infrastructure, mobile internet users face questions: what resources remain available, and what does this look like on a technical level? This material is the result of a practical study using standard network analysis tools.
No speculation—only measurements, numbers, and technical facts.
Disclaimer: This article is for educational and research purposes only. All measurements were conducted on a personal device for the legal purpose of studying network traffic.
Research Methodology
Test Setup
[iPhone с мобильным интернетом] ↓ (режим модема) [MacBook] ↓ (тестирование + захват) [Bash-скрипты + Wireshark]
Why this setup:
Mobile internet shows the current state of filtering at the operator level;
Tethering mode does not distort traffic;
A MacBook allows the use of professional tools.
What Was Tested
For objectivity, a list of 26 domains in several categories was compiled:
Category | Quantity | Examples |
|---|---|---|
Government services | 4 | |
Russian social networks | 3 | |
Yandex services | 3 | |
Marketplaces | 3 | |
Media | 1 | |
Telecom operators | 5 | mts.ru, beeline.ru, megafon.ru and others. |
Payment systems | 1 | |
Control: neutral foreign | 3 | |
Control: known blocked | 3 |
Testing Parameters
For each domain, the following were performed:
DNS queries to two servers:
Yandex DNS (77.88.8.8)
Google DNS (8.8.8.8)
ICMP Ping (3 packets) — checking IP availability
HTTPS request with a 10-second timeout
Traceroute (first 5 hops) — route to the host
Time of test: November 5, 2025, 22:58–23:11 (MSK)
Duration: 13 minutes
Parallel capture: Wireshark (PCAPNG format)
Results: The Raw Numbers
Overall Statistics
Out of 26 tested domains:
Status | Quantity | Percentage |
|---|---|---|
✅ Fully working (HTTP 2xx/3xx) | 11 | 42% |
⚠️ DNS resolves, but HTTP does not work | 14 | 54% |
❌ Completely unavailable (even DNS) | 1 | 4% |
Detailed Results Table
Domain | Category | DNS (Yandex) | DNS (Google) | Ping | HTTPS | Response time |
|---|---|---|---|---|---|---|
Social networks RU | ✅ | ❌ | ✅ | ✅ 200 | 451ms | |
Social networks RU | ✅ | ❌ | ✅ | ✅ 200 | 66ms | |
Social networks RU | ✅ | ❌ | ✅ | ✅ 302 | 187ms | |
Yandex | ✅ | ❌ | ✅ | ✅ 302 | 387ms | |
Yandex | ✅ | ❌ | ✅ | ✅ 302 | 349ms | |
Yandex | ✅ | ❌ | ❌ | ✅ 302 | — | |
Marketplace | ✅ | ❌ | ✅ | ✅ 307 | 478ms | |
Marketplace | ✅ | ❌ | ❌ | ✅ 307 | — | |
Marketplace | ✅ | ❌ | ❌ | ✅ 301 | — | |
Media | ✅ | ❌ | ✅ | ✅ 200 | 342ms | |
Operator | ✅ | ❌ | ✅ | ✅ 302 | 478ms | |
Gosuslugi | ✅ | ❌ | ❌ | ❌ | timeout | |
Gov | ✅ | ❌ | ❌ | ❌ | timeout | |
Gov | ✅ | ❌ | ❌ | ❌ | timeout | |
Gov | ✅ | ❌ | ❌ | ❌ | timeout | |
Operator | ✅ | ❌ | ❌ | ❌ | timeout | |
Operator | ✅ | ❌ | ❌ | ❌ | timeout | |
Operator | ✅ | ❌ | ❌ | ❌ | timeout | |
t2-mobile.ru | Operator | ✅ | ❌ | ❌ | ❌ | timeout |
Foreign | ✅ | ❌ | ❌ | ❌ | timeout | |
Foreign | ✅ | ❌ | ❌ | ❌ | timeout | |
Foreign | ✅ | ❌ | ❌ | ❌ | timeout | |
Blocked | ✅ | ❌ | ❌ | ❌ | timeout | |
Blocked | ✅ | ❌ | ❌ | ❌ | timeout | |
Blocked | ✅ | ❌ | ❌ | ❌ | timeout | |
Payment | ❌ | ❌ | ❌ | ❌ | — |
Key Findings
1. Google DNS is completely unavailable
Результат для ВСЕХ 26 доменов: DNS (Google): ;; connection timed out; no servers could be reached
Conclusion: Google's DNS server (8.8.8.8) does not respond to any queries. This indicates a restriction at the operator level.
2. Yandex DNS works selectively
Yandex DNS (77.88.8.8) successfully resolves 25 out of 26 domains (96%), including:
All Russian services
Government portals
Foreign resources (Wikipedia, GitHub)
Blocked social networks (Twitter, Facebook)
But: DNS resolution does not guarantee availability!
3. Intermediate Operator Router
For all working connections, a hop appears in the traceroute:
198.18.9.129 ~33-40ms
What is this:
198.18.0.0/15 — a range for CGNAT (Carrier-Grade NAT)
This is the operator's gateway/router with NAT
Allowed traffic is routed through it
Blocked traffic is dropped BEFORE this hop
For non-working connections, this hop is not present:
1 172.20.10.1 (локальный шлюз) 2 * * * 3 * * *
4. Government services are not working (a paradox!)
Gosuslugi is on the "official whitelist," but:
gosuslugi.ru: DNS (Yandex): 213.59.253.7 ✅ резолвится Ping: timeout ❌ не отвечает HTTPS: Connection failed ❌ не подключается Traceroute: только локальный шлюз
The same goes for:
This is a critical finding: even services from the official list are unavailable.
5. Telecom operators: 1 out of 5 works
Of the five operator portals, only mts.ru is available. The rest (beeline.ru, megafon.ru, rostelecom.ru, t2-mobile.ru) have DNS, but a TCP connection cannot be established.
6. The control group confirms the picture
Neutral foreign resources:
Wikipedia ❌
GitHub ❌
StackOverflow ❌
DNS resolves, but HTTPS does not work—identical to gosuslugi.
Known blocked sites:
Twitter ❌
Facebook ❌
Instagram ❌
The behavior is exactly the same as with gosuslugi and foreign resources.
Technical Analysis
Filtering Architecture
Based on the data, the following scheme can be reconstructed:
┌──────────────┐ │ Клиент │ │ (172.20.x) │ └──────┬───────┘ │ ↓ ┌──────────────┐ │ Локальный │ │ шлюз │ │ (172.20.10.1)│ └──────┬───────┘ │ ↓ ╔══════════════════════════╗ ║ Фильтр оператора ║ ║ (уровень 1: DNS) ║ ╟──────────────────────────╢ ║ • Google DNS → блок ║ ║ • Yandex DNS → OK ║ ╚═════════╦════════════════╝ │ ↓ ╔══════════════════════════╗ ║ Фильтр оператора ║ ║ (уровень 2: IP/фильтр) ║ ╟──────────────────────────╢ ║ IF (IP in whitelist): ║ ║ → ROUTE (маршрутизация)║ ║ ELSE: ║ ║ → DROP ║ ╚═════════╦════════════════╝ │ ↓ (только разрешённые) ┌─────────────────┐ │ 198.18.9.129 │ │ (CGNAT-шлюз) │ └────────┬────────┘ │ ↓ ┌─────────────────┐ │ Интернет │ └─────────────────┘
Why does DNS resolve, but the site doesn't open?
This is the classic behavior of two-level filtering:
Level 1 — DNS:
Yandex DNS works and returns real IP addresses
This creates the illusion that "everything resolves"
Level 2 — IP filtering at the routing level:
Packets to "unauthorized" IPs are dropped at the router level
No RST, no ICMP unreachable
just silence - The client waits for a timeout (10 seconds in our test)
Allowed packets pass through the CGNAT gateway (198.18.9.129) and on to the internet
The Role of 198.18.9.129
This IP is the key to understanding the mechanism:
This is the operator's CGNAT gateway for routing allowed traffic.
How it works:
1. The client makes a DNS query → receives a real IP (e.g., vk.com = 87.240.x.x)
2. The client sends a SYN to this IP
3. The operator checks the destination IP in the packet
4. If the IP is on the whitelist: the packet is routed through the operator's infrastructure (including 198.18.9.129)
5. If not: the packet is simply dropped at the routing level
Confirmation:
# Все работающие сервисы: traceroute vk.com 1 172.20.10.1 2 198.18.9.129 ← CGNAT-шлюз оператора 3 * * * ← дальше в интернет # Все неработающие: traceroute gosuslugi.ru 1 172.20.10.1 2 * * * ← трафик дропается, не маршрутизируется 3 * * *
Comparative Analysis
What Works: Indicators
Characteristic | Value |
|---|---|
DNS via Yandex | ✅ Yes |
Intermediate hop 198.18.9.129 | ✅ Present |
Ping works | ✅/⚠️ Yes (not always) |
HTTPS code | 2xx or 3xx |
Response time | 66ms–478ms |
Categories:
Russian social networks (VK, OK, Mail.ru)
Yandex services
Marketplaces (Ozon, Wildberries, Avito)
Rutube
MTS
What Doesn't Work: Indicators
Characteristic | Value |
|---|---|
DNS via Yandex | ✅ Resolves |
Intermediate hop 198.18.9.129 | ❌ Absent |
Ping works | ❌ Timeout |
HTTPS | Connection timeout |
Traceroute | Stops at the local gateway |
Categories:
Government portals (!)
Most telecom operators
Foreign resources
Known blocked social networks
Paradoxes and Anomalies
1. Gosuslugi is unavailable
Expectation: As a government portal, it should be a priority
Reality: It doesn't open, despite DNS resolution
Possible reasons:
The IP address of gosuslugi is not on the operator's whitelist
Technical routing failure
Temporary changes in filtering
2. VK.com works without DNS
vk.com: DNS (Yandex): timeout DNS (Google): timeout Ping: OK (451ms) HTTPS: 200 OK
How is this possible?
There was likely a cached DNS response in the system
Or the connection is made directly via IP without a new DNS query
Curl uses /etc/hosts or the system cache
3. Operators don't open their own websites
4 out of 5 telecom operators cannot provide access to their portals through their own network. The story here is quite simple - only the site of the operator being used opens. I use MTS.
4. No difference between Wikipedia and Twitter
From a network behavior perspective, a neutral educational resource (Wikipedia) and a known blocked service (Twitter) behave absolutely identically:
DNS resolves ✅
TCP connection fails ❌
Traceroute to the local gateway
This indicates positive filtering (a whitelist), rather than blocking specific resources.
Conclusions
1. The "whitelist" model is confirmed
The data convincingly shows positive filtering:
Not "blocking the bad," but "allowing the good"
Anything not on the list is unavailable by default
Even government resources might not make it onto the list
2. Google DNS is completely blocked
100% of queries to 8.8.8.8 result in a timeout. This is an intentional block of alternative DNS servers.
3. Two-level filtering
Уровень 1: DNS (контролируется выбором DNS-сервера) Уровень 2: IP/Transport (жёсткая фильтрация на стороне оператора)
4. CGNAT gateway for routing allowed traffic
IP 198.18.9.129 (CGNAT range) is the operator's router with NAT. All allowed traffic passes through it. Blocked traffic is dropped before this gateway and is not routed at all.
5. Instability even on the "whitelist"
Formally allowed resources (gosuslugi, operators) are often unavailable, which indicates:
Imperfect implementation
Dynamic changes to the lists
Possible technical errors
What This Means for Specialists
For Developers
If your service becomes unavailable:
# Проверьте DNS-резолвинг dig +short your-service.com @77.88.8.8 dig +short your-service.com @8.8.8.8 # Если Yandex резолвит, но Google нет — это первый сигнал # Проверьте TCP-соединение curl -v --connect-timeout 5 https://YOUR-IP # Traceroute покажет, где обрывается маршрут traceroute -m 10 your-service.com
If you see:
DNS works
Traceroute breaks at the 1st-2nd hop
Curl hangs and times out
→ Your IP is not on the operator's whitelist.
For System Administrators
Troubleshooting:
DNS level:
Use multiple DNS servers for verification
Yandex DNS (77.88.8.8) is the main working option
Transport level:
A tcpdump/Wireshark capture will show where packets are being dropped
Look for SYN without SYN-ACK
Routing:
MTR will show the full path and packet loss
Pay attention to hops in the 198.18.0.0/15 range
For Business
If your B2C/B2B service is critical:
Hosting on Russian servers may improve availability
Coordinating with operators to be included in the whitelist
Monitoring availability from different operators
Alternative entry points (mirrors, CDN)
Methodological Notes
Study Limitations
One operator, one point in time
Data was collected from only one mobile operator
The situation may differ at other times of the day
Limited list of domains
26 domains were tested
The actual whitelist may contain thousands of entries
A snapshot, not continuous monitoring
This is a snapshot from November 5, 2025
The lists can change dynamically
Reproducibility
All tools used are standard:
# DNS dig @77.88.8.8 domain.com # Ping ping -c 3 domain.com # HTTP curl -v --connect-timeout 5 https://domain.com # Traceroute traceroute -m 5 domain.com
Automation scripts are available upon request (under the MIT license).
Conclusion
This study shows that the mobile internet network infrastructure in Russia operates on a strict whitelist model:
✅ What works:
A limited set of Russian services
Major social networks (VK, OK)
Marketplaces
Yandex services
❌ What doesn't work:
Most foreign resources
Alternative DNS servers
Even some government portals
🔍 Technical implementation:
Two-level filtering (DNS + IP/Transport)
Proxy layer for allowed traffic
Complete blocking of Google DNS
It is important for technical specialists to understand these mechanisms to correctly diagnose availability issues and design resilient systems.
Additional Materials
Tools
Wireshark — https://www.wireshark.org/
tcpdump — built into macOS/Linux
dig —
brew install bind/apt install dnsutilsmtr —
brew install mtr/apt install mtr
Useful Commands
# Быстрая проверка доступности curl -I -m 5 https://example.com # DNS через разные серверы dig example.com @77.88.8.8 +short dig example.com @8.8.8.8 +short # Маршрут с потерями пакетов mtr -r -c 10 example.com # Захват трафика для анализа sudo tcpdump -i any -w capture.pcap port 443 or port 53
Wireshark Filters
# DNS-запросы и ответы dns # Сброшенные TCP-соединения tcp.flags.reset == 1 # Неотвеченные SYN tcp.flags.syn == 1 and tcp.flags.ack == 0 # Трафик к конкретному IP ip.addr == 198.18.9.129
Publication Date: November 2025
Author: Technical analysis based on real measurements
License: This article was created for educational purposes
The author does not call for breaking the law and does not provide instructions on how to bypass restrictions. All data was obtained by legal methods using standard network diagnostic tools.
A small addition to clarify the reason for my detailed analysis. For two weeks now, I haven't been able to access my banking apps to make payments in stores using mobile internet; only Yandex Pay works. No messengers work, except for MAKS. Avito and Ozon work, but something like Apple Music does not.