Ник Пост Дата
ValdikSS

Вечером 27 апреля 2020 года в Лебапской и Марыйской областях Туркменистана прошел сильный ураган с ливнем, поваливший деревья, снесший крыши домов и затопивший различные постройки. За прошедшую неделю власти Туркменистана умалчивали инцидент, не сообщая о нём в официальных СМИ.
Жилетям Марыйской, Чарджовской, Дашовуской областей отключили доступ в интернет 28 апреля 2020 года, на следующий день после урагана, после появления фото- и видеокадров с мест событий.

Сайт hronikatm.com сообщает следующее:

Организация напоминает, что в стране нет свободы СМИ – государственные СМИ доминируют, а власти блокируют большинство независимых и западных масс-медиа.

Власти пытались помешать жителям обнародовать визуальные документы, документирующие разрушение урагана. Базирующейся в Праге правозащитной группе «Права и свободы туркменских граждан» удалось поговорить с женщиной, которую МНБ задерживали в течение двух дней вместе с 29 другими, обвинив их в отправке видео «за границу». По этой же причине МНБ задержали еще 19 женщин в Туркменабате, освободив их 3 мая. «Туркменская инициатива по правам человека» (ТИПЧ) заявила, что полиция наблюдает за людьми в автомобилях, снимающими повреждения на свои мобильные телефоны.

Цензура и усилия туркменских властей по предотвращению обнародования информации о нанесенном ущербе затрудняют его точную оценку. Радио «Свобода» заявило о 30 погибших. Turkmen news говорили с медицинским чиновником, который рассказал о 300 погибших в Туркменабате. Большинство зданий в городе повреждены. Небольшие города также сильно повреждены ветрами и наводнениями. Распространяется видео с домами без крыш и серьезными повреждениями внутри.

Мне довелось получить интернет-канал с доступом извне Туркменистана, и протестировать доступность в условиях интернет-шатдауна в г. Мары. Провайдер — КЭ “Туркментелеком” (TMTelecom), домашнее проводное подключение через ADSL.
Туркменистанец, предоставивший интернет-канал, сообщает, что недоступность сайтов наблюдается в 3 регионах страны, на проводном и мобильном интернете, из чего я делаю вывод о намеренном отключении интернета правительством. Мне не удалось обнаружить никаких публичных заметок об этом где-либо в интернете, в т.ч. на сайтах, специализирующихся на новостях из Туркменистана.

Кратко: техническая IP-связность с другими странами сохраняется, но доступ до фактически всех интернет-сайтов и сервисов заблокирован с помощью системы DPI. Сайты не открываются, приложения не работают.

DNS

Работа DNS, по сравнению с обычной ситуацией в Туркменистане, не изменилась: популярные сторонние публичные DNS-резолверы частично недоступны, из-за блокировки диапазонов крупных хостинг-провайдеров в интернет-компаний по IP-диапазонам (типичная ситуация для Туркменистана, а не особенность этой недели).

Не работают: 1.1.1.1, 8.8.8.8, 9.9.9.9
Работают: 77.88.8.8, 193.17.47.1, 185.43.135.1

Запросы IP-адресов некоторых доменов подвергаются DNS-спуфингу, причем на любом IP-адресе и UDP-порту.
Например, запрос rutracker.org через 77.88.8.8 возвращает 127.0.0.1:

# host rutracker.org 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases: 

rutracker.org has address 127.0.0.1
rutracker.org has address 127.0.0.1
rutracker.org has address 127.0.0.1

Аналогичная ситуация происходит при попытке запроса этого домена через порт 1253 — малоизвестный недокументированный порт, на котором работает Яндекс.DNS 77.88.8.8

HTTP и HTTPS

В условиях интернет-шатдауна сайт может быть более-менее доступен по HTTP, но не по HTTPS, и наоборот (!).
При попытке открыть сайт, соединение либо не принимается (словно нет сетевой связности, не приходит ответ на TCP SYN), либо принимается, но разрывается или «застывает» (перестают приходить ответные TCP ACK и любые другие пакеты).
Задержка между приёмом соединения и началом передачи данных может достигать 10-12 секунд. Вероятно, это вызвано проверками соединения системой DPI.
Порты 55, 88, 89, 1080, 3128 заблокированы (это типичная ситуация), соединение к ним всегда сбрасывается (TCP RST), независимо от IP-адреса назначения. Некоторые (высокие) порты временами перестают работать, закономерность не выявлена.

Не работают (могут периодически хоть как-то отвечать, в частности, по нешифрованному HTTP, но до конца точно никогда не открываются):

Работают:

  • google.com (фактически единственный домен, более-менее нормально работающий по HTTPS, который удалось обнаружить, при этом поддомены и другие сервисы вроде gmail не работают)
  • online.tm и telecom.tm (сайты провайдера)

Пример неработающего сайта gismeteo. Запрос по HTTP принимается, но соединение разрывается:

* Connected to www.gismeteo.ru (185.134.203.108) port 80 (#0)
> GET / HTTP/1.1
> Host: www.gismeteo.ru
> User-Agent: curl/7.64.0
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host www.gismeteo.ru left intact
curl: (52) Empty reply from server

По HTTPS:

*   Trying 185.134.202.21...
* TCP_NODELAY set
* Connected to www.gismeteo.ru (185.134.202.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):

И так до бесконечности, пакеты перестают ходить.

Пример соединения с yandex. Соединение по HTTP принимается, но ответа не поступает, и соединение «зависает». Я подделал заголовки на браузерные, чтобы исключить фильтрацию curl:

* Connected to yandex.ru (77.88.55.55) port 80 (#0)
> GET / HTTP/1.1
> Host: yandex.ru
> Accept-Encoding: deflate, gzip
> User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Language: ru,en;q=0.7,en-US;q=0.3
> DNT: 1
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1
> Pragma: no-cache
> Cache-Control: no-cache
>

Попытка открыть mail.yandex.ru по HTTPS:

*   Trying 77.88.21.37...
* TCP_NODELAY set
* Connected to mail.yandex.ru (77.88.21.37) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Аналогично, последующих ответов от сервера не поступает.

Другие протоколы

Ситуация с другими протоколами в целом аналогична HTTP/HTTPS. Хост может хоть как-то быть доступен по HTTP (TCP port 80), но по SSH к нему подключиться не получится: произойдет либо разрыв соединения, либо «зависание».

root@debian-tm:~# ssh example.com -vvv
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname example.com is address
debug2: ssh_connect_direct
debug1: Connecting to example.com [1.2.3.4] port 22.
debug1: connect to address 1.2.3.4 port 22: Connection refused
ssh: connect to host 1.2.3.4 port 22: Connection refused

UDP позволяет передавать трафик от 7 до 10 секунд, после чего пакеты перестают отправляться в обе стороны на этой связке клиентского и серверного UDP-портов. За 10 секунд можно успеть передать около 200 КБ данных. Предположительно, блокировка сделана именно так, чтобы оставить работоспособными DNS, NTP и другой важный UDP-трафик.

ICMP-пакеты заблокированы в целом для хостов вне страны, доставляется только (условно) первый запрос и ответ (любого ICMP-типа), вероятно, чтобы не применяли ICMP-туннели. Из-за этого ICMP Echo Request/Echo Reply (более известен как ping) удается получить максимум один в несколько десятков секунд (когда система «забудет» о первом отправленном пакете). Сайт провайдера при этом «пингуется» нормально.

По TCP в общем чаще всего соединение устанавливается нормально, но передаётся или принимается только первый килобайт трафика после установки соединения, после чего пакеты перестают ходить в обе стороны (что и вызывает «зависание» соединения на разных протоколах). Проблема не вызывана MTU: я уменьшал TCP MSS до низких значений, и удостоверивался, что даже маленькие пакеты (<400 байт) перестают передаваться.
Предполагаю, что так работает DPI: происходит анализ до 1 КБ ответного трафика от сервера, из которого система принимает решение о разрешении или блокировании запроса.
Для подтверждения этого предположения я сделал перенаправление трафика с моего сервера в интернете на www.google.com на порту 443, и подключился к IP сервера так, словно это Google, по HTTPS — это сработало, трафик нормально ходил в обе стороны, соединение не переставало работать после 1 КБ переданных или полученных данных. По всей видимости, DPI в этом килобайте ожидает X.509 (HTTPS)-сертификат доверенного сайта (www.google.com в данном случае).
Я пробовал подделывать сертификат Google путём создания его точной копии (с такими же полями), но, похоже, проверяется всё тело сертификата целиком, а не только заголовки.

Способы получения интернета в условиях его отключения

Несмотря на отключения интернета правительством и неработоспособность сайтов, в регионе всё ещё технически сохраняется IP-связность с внешним интернетом.

Есть, по меньшей мере, два рабочих способа получения интернета на предоставленном мне канале:

  • Так как сохраняется доступ по крайней мере на один сайт (www.google.com), а проверка сайта осуществляется по домену и сертификату, но не IP-адресу, то можно воспользоваться программой Cloak от @antikythera, для создания туннеля, замаскированного под сайт Google.
  • Из-за сохранения стабильной работы DNS, можно, в качестве крайней меры, организовать DNS-туннель программой iodine или dnstt: он медленный и не самый стабильный в силу своей специфики, но для соединения к серверу по SSH достаточен.
  • TCP-пакеты SYN и SYN-ACK (начало соединения и ответ на начало соединения) продолжают доставляться в целом стабильно, можно организовать туннель на их основе. Готовые программы мне для этого неизвестны, но, вероятно, можно адаптировать udp2raw.

Выводы

В условиях интернет-шатдауна, вызванного действиями внутри страны, а не неисправностями транзитных каналов, всё равно можно найти способы получения доступа в интернет, но для этого нужно обладать глубокими знаниями в сетевых технологиях, набором программ и пониманием принципов их работы, а также заранее заготовленным сервером вне страны.

Самым надёжным резервным способом связи с зарубежным сервером остаётся, по моему мнению, DNS-туннель — работоспособность DNS, с большой вероятностью, будет поддерживаться провайдерами дольше всего, а значит, можно воспользоваться заранее настроенным DNS-туннелем для дальнейшей настройки зарубежного сервера в условиях отсутствия полноценной сетевой связности.

2020-05-05T21:02:20.652Z
tango

@ValdikSS’s post was too long for the forum’s auto-translation. Here is the text translated using DeepL Translate: The world's most accurate translator.

Internet blackout in Mary, Turkmenistan, April-May 2020

In the evening of April 27, 2020, a strong hurricane with heavy downpours took place in Lebap and Mary regions of Turkmenistan, which fell trees, demolished roofs of houses and flooded various buildings. Over the past week, the authorities of Turkmenistan kept silent about the incident without reporting it to the official media.
Residents of Mary, Chardzhou, and Daşoguz Oblasts were disconnected from the Internet on April 28, 2020, the day after the storm, after photos and video footage from the scene appeared.

The website hronikatm.com reports the following:

The organization reminds that there is no freedom of media in the country - state media are dominant, while the authorities block most independent and Western media.

The authorities have tried to prevent residents from publishing visual documents documenting the destruction of the hurricane. Prague-based human rights group “Rights and Freedoms of Turkmen Citizens” managed to talk to a woman who was detained by MNB for two days along with 29 others, accusing them of sending the video “abroad”. For the same reason, DHS detained 19 other women in Turkmenabat, releasing them May 3. "The Turkmen Human Rights Initiative (TIHR) said police are watching people in cars taking pictures of injuries on their mobile phones.

Censorship and efforts by the Turkmen authorities to prevent the damage from being made public make it difficult to accurately assess the damage. Radio Liberty reported 30 deaths. Turkmen news talked to a medical official who reported 300 deaths in Turkmenabat. Most buildings in the city have been damaged. Small towns are also heavily damaged by winds and floods. A video of houses without roofs and severely damaged inside is being distributed.

I had the opportunity to get an Internet channel with access from outside Turkmenistan, and to test availability in the conditions of an Internet shutdown in Mary. The provider is TMTelecom, a home wired connection via ADSL.
The Turkmen, who provided the Internet channel, reports that the inaccessibility of sites is observed in 3 regions of the country, on wired and mobile Internet, from which I conclude that the government deliberately shut down the Internet. I have not been able to find any public notes about it anywhere on the Internet, including sites specializing in news from Turkmenistan.

Briefly: technical IP connection with other countries is preserved, but access to virtually all Internet sites and services is blocked using DPI system. Sites are not opened, applications do not work.

DNS

The operation of DNS, compared to the usual situation in Turkmenistan, has not changed: popular third-party public DNS resellers are partially unavailable due to blocking the ranges of large hosting providers to Internet companies over IP ranges (a typical situation for Turkmenistan, not a feature of this week).

Not working: 1.1.1.1, 8.8.8.8, 9.9.9.
Working: 77.88.8.8, 193.17.47.1, 185.43.135.1

Requests for IP addresses for some domains are subject to DNS spoofing, at any IP address and UDP port.
For example, the rutracker.org request returns 127.0.0.1 after 77.88.8.8:

# host rutracker.org 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases: 

rutracker.org has address 127.0.0.1
rutracker.org has address 127.0.0.1
rutracker.org has address 127.0.0.1

A similar situation occurs when attempting to query this domain on port 1253, a little-known undocumented port on which Yandex.DNS 77.88.8.8 is running.

HTTP and HTTPS

In Internet Shutdown conditions the site can be more or less accessible via HTTP, but not via HTTPS, and vice versa (!).
At attempt to open a site, connection either is not accepted (as if there is no network connection, the answer to TCP SYN does not come), or is accepted, but breaks off or “freezes” (stops coming reply TCP ACK and any other packets).
There can be a delay of 10-12 seconds between receiving a connection and starting data transfer. This is probably due to the DPI connection checks.
Ports 55, 88, 89, 1080, 3128 are blocked (this is a typical situation) and the connection to them is always reset (TCP RST), regardless of the destination IP address. Some (high) ports stop working at times, the pattern is not detected.

These do not work (they may occasionally respond in some way, particularly with unencrypted HTTP, but they never open until the end):

These work:

  • google.com (actually the only domain more or less normally operating over HTTPS that has been detected, with subdomains and other services like gmail not working)
  • online.tm and telecom.tm (provider sites)

An example of a gismeteo site not working. An HTTP request is accepted, but the connection is broken:

* Connected to www.gismeteo.ru (185.134.203.108) port 80 (#0)
> GET / HTTP/1.1
> Host: www.gismeteo.ru
> User-Agent: curl/7.64.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host www.gismeteo.ru left intact
curl: (52) Empty reply from server

Over HTTPS:

*   Trying 185.134.202.21...
* TCP_NODELAY set
* Connected to www.gismeteo.ru (185.134.202.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):

And so to infinity, the packets stop moving.

Example of a yandex connection. An HTTP connection is accepted, but no response is received, and the connection “hangs”. I forged the headers on the browser to exclude curl filtering:

* Connected to yandex.ru (77.88.55.55) port 80 (#0)
> GET / HTTP/1.1
> Host: yandex.ru
> Accept-Encoding: deflate, gzip
> User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Language: ru,en;q=0.7,en-US;q=0.3
> DNT: 1
> Connection: keep-alive
> Upgrade-Insecure-Requests: 1
> Pragma: no-cache
> Cache-Control: no-cache
>

Attempt to open mail.yandex.ru via HTTPS:

*   Trying 77.88.21.37...
* TCP_NODELAY set
* Connected to mail.yandex.ru (77.88.21.37) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Similarly, no further responses are received from the server.

Other protocols

The situation with other protocols is generally similar to HTTP/HTTPS. The host can somehow be accessed via HTTP (TCP port 80), but it will not be possible to connect to it via SSH: either the connection will be broken or “hanging”.

root@debian-tm:~# ssh example.com -vvv
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname example.com is address
debug2: ssh_connect_direct
debug1: Connecting to example.com [1.2.3.4] port 22.
debug1: connect to address 1.2.3.4 port 22: Connection refused
ssh: connect to host 1.2.3.4 port 22: Connection refused

UDP allows traffic from 7 to 10 seconds, after which the packets are no longer sent both ways on this bundle of client and server UDP ports. About 200 KB of data can be transmitted in 10 seconds. Presumably, the blocking is designed to leave DNS, NTP and other important UDP traffic running.

ICMP packets are generally blocked for hosts outside the country, only the (conditionally) first request and response (of any ICMP type) is delivered, probably to avoid ICMP tunnels. Because of this, ICMP Echo Request/Echo Reply (better known as ping) manages to get a maximum of one in a few tens of seconds (when the system “forgets” the first packet sent). The provider’s site is normally “pinged” in this case.

On TCP in general most often connection is established normally, but only the first kilobyte of the traffic after connection establishment is transferred or accepted, then packets stop to go in both parties (that causes “hanging” of connection on different protocols). The problem is not caused by MTU: I reduced TCP MSS to low values and made sure that even small packets (<400 bytes) stop transmitting.
I assume that this is how DPI works: up to 1 KB of response traffic from the server is analyzed and the system decides whether to allow or block the request.
To confirm this assumption, I redirected traffic from my server on the Internet to www.google.com on port 443, and connected to the IP server as if it were Google, over HTTPS - it worked, the traffic went both ways normally, the connection did not stop working after 1 KB of transmitted or received data. Apparently, the DPI in this kilobyte expects an X.509 (HTTPS) certificate from a trusted site (www.google.com in this case).
I tried to tamper with the Google certificate by making an exact copy of it (with the same fields), but it looks like the entire body of the certificate is being checked, not just the headers.

How to get the Internet when it’s turned off

Despite the government’s disconnection of the Internet and the inoperability of sites, the region still technically maintains IP connectivity to the external Internet.

There are at least two working ways to get the Internet on the channel provided to me:

  • Since at least one site (www.google.com) is still accessible and the site is checked by domain and certificate, but not IP address, you can use Cloak from @antikythera to create a tunnel disguised as a Google site.
  • Due to the stability of DNS, you can, as a last resort, organize a DNS-tunnel program iodine: it is slow and unstable due to its specifics, but enough to connect to the server via SSH.
  • TCP packets SYN and SYN-ACK (start of connection and start response) continue to be delivered generally stable, you can organize a tunnel based on them. I don’t know the ready-made programs for this, but it is probably possible to adapt udp2raw.

Conclusions

In conditions of the Internet shutdown caused by actions inside the country, instead of malfunctions of transit channels, it is still possible to find ways of access to the Internet, but for this purpose it is necessary to possess profound knowledge in network technologies, a set of programs and understanding of principles of their work, and also in advance prepared server out of the country.

The most reliable backup method of communication with a foreign server is, in my opinion, the DNS-tunnel - the performance of DNS, with a high probability, will be supported by providers for the longest time, and therefore, you can use a pre-configured DNS-tunnel for further configuration of the foreign server in the absence of full network connectivity.

2020-05-05T21:44:06.966Z
tango

https://www.bamsoftware.com/software/dnstt/
https://github.com/net4people/bbs/issues/30

Recently I published this new DNS tunnel. It has not had much testing yet, but I believe it can have better performance than iodine. I wrote the tunnel to take advantage of the possibilities of DNS over HTTP and DNS over TLS, but it can also run in plaintext UDP mode. (Obviously it is in principle easily detectable in UDP mode.)

Unfortunately it’s still a new project and you have to be somewhat technical to use it. It doesn’t provide a TUN interface like iodine does, nor even SOCKS; you have to run your own SOCKS proxy on the server if you want the tunnel to work as a proxy. The code is public domain so you are free to adapt it according to requirements, and I’m open to suggestions and willing to help.

2020-05-05T22:00:10.634Z
ValdikSS

By the readme, I assume dnstt could use only DoH, DoT or direct UDP mode, and not a regular DNS? If this is the case, it won’t work in Turkmenistan shutdown conditions because UDP traffic is also blocked after several seconds. It would probably work only for several seconds and then hang, requiring to reconnect/change client’s UDP port.

2020-05-05T22:25:30.486Z
tango

I don’t know what you mean by regular DNS. dnstt uses normal DNS messages and ordinary public DNS recursive resolvers. The recursive resolver can be DoH, DoT, or classical UDP DNS. There’s also a mode where the tunnel client communicates directly with the tunnel server, but that mode is only for debugging and performance comparisons. If all UDP associations are blocked after a few seconds, then it seems iodine would not work either, because it relies on repeated UDP packets to the same resolver address as well.

For some resolvers you may have to reduce the DNS response size on the server with -mtu 512, but other than that it should work with any recursive resolver, whether an ISP resolver or a public one like Google DNS. However it has not been tested in many environments and it’s possible there are compatibility bugs.

2020-05-05T22:37:24.411Z
ValdikSS

I see, that wasn’t clear from the readme. I assumed that it works only over DoH, DoT and using custom protocol over UDP with direct connection to the server (without using DNS at all).

It would, but not in direct mode. Iodine has two modes of operation: DNS requests/replies over any available DNS resolver, and direct mode with direct UDP connection to the server. I assume only the former would work in this conditions.

2020-05-05T22:46:17.279Z
tango

I see. Thank you for the comment. I will look at the documentation and perhaps make some changes. I wanted to de-emphasize the UDP DNS support because it’s not covert like DoH and DoT are; classical DNS tunnels are easy to detect and block (including iodine). But I mention it in this case because the situation sounds extreme and there may be some short-term usefulness even in the UDP mode. Anyway I apologize, I did not mean to hijack the topic.

2020-05-05T23:18:45.794Z
thebadgateway

Спасибо за статью, очень познавательно, особенно когда дал на днях знакомому в Туркменистане свой сервер V2ray и ему хватило им пользоваться пару минут в лучшем случае.

2020-05-06T03:24:39.777Z
ValdikSS

Протестировал dnstt от @tango в Туркменистане — работает стабильно и быстро при прямом UDP-соединении с сервером. UDP-соединение не «зависает» — видимо, блокировки DPI не применяются для DNS-трафика.

2020-05-06T15:13:43.664Z
thebadgateway

Глянул мельком на страницу про dnstt. Я так понимаю клиент там только один и под смартфоны не кто не писал его?

2020-05-07T02:28:28.411Z
ValdikSS

Забыл написать, что доступ к www.google.com перестал работать через несколько часов после публикации первого сообщения, хотя до этого работал двое суток без перебоев.

Когда начал анализировать ситуацию, вспомнил, что при соединении к www.google.com используется TLS v1.3, в котором шифруется серверный сертификат, поэтому DPI не мог анализировать именно сертификат в ответе сервера. Почему и как это работало раньше — непонятно, вероятно, в DPI были сделаны какие-то исключения для определенных размеров ответных пакетов (?).

2020-05-07T10:46:00.096Z
bolvan

Не пробовал нестандартные IP протоколы ?

2020-05-09T18:52:44.980Z
ValdikSS

Пробовал отправлять пустые пакеты со всеми возможными идентификаторами протоколов — ничего не доходило (но это могло быть из-за NAT роутера и из-за Virtualbox, но в Virtualbox был bridge).

2020-05-09T19:03:59.229Z
0ka(0ka)

Кажется, блокировки стали менее жесткими в этом году?

2021-05-26T07:38:14.538Z
VasilyGrigoriev378(Василий Григорьев)

Как обойти блокировки в Туркменистане просто все впн сдохли не пашут блочат их. Типа Goodbye DPI есть такой же инструмент для Туркменов?

2021-06-10T19:19:31.492Z
0ka(0ka)

Да заглохли щас блоки, глянь https://4pda.to/forum/index.php?showtopic=1009120&view=findpost&p=106794738
Твой ник немного напугал меня т.к. в whois айпишников ТМ написан Alex Grigoriev)

2021-06-11T00:47:28.562Z