Вечером 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, но до конца точно никогда не открываются):
- mail.ru
- yandex.ru
- microsoft.com
- habr.com
- gmail.com
- github.com
- mozilla.org
- wikipedia.org
- bing.com
- rambler.ru
- yahoo.com
- icanhazip.com
- icloud.com
- apple.com
- rambler.ru
- click.alfabank.ru
- online.vtb.ru
- msftncsi.com (домен для проверки доступности интернет-соединения в Windows)
- connectivitycheck.gstatic.com (домен для проверки доступности интернет-соединения в Android)
Работают:
- 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-туннелем для дальнейшей настройки зарубежного сервера в условиях отсутствия полноценной сетевой связности.