Обход DPI провайдера на роутере с OpenWrt, используя только busybox

    image
    Всем привет, в свете последних новостей от РосКомНадзора решил я глянуть, как дела с блокировками у моего провайдера. Оказалось, что гугловский DNS не спасает, а блокировка работает путем выделения HTTP запроса на запрещенный сайт и последующего дропания пакетов найденной TCP сессии. Однако после небольшого ковыряния оказалось, что для обхода достаточно одного busybox'а. Кому интересно — велком под кат.



    Сразу оговорюсь, что реализация блокировки зависит от провайдера и мой способ может у вас не сработать. Итак, рассматривать будем на примере всем известного сайта rutracker.ogr (домен и IP адрес в посте изменен во избежание).
    Начал я с простого запроса, чтобы посмотреть, как в целом реагирует провайдер.

    Запрос главной страницы
    wget -O/dev/null "rutracker.ogr"
    --2016-02-10 01:21:18--  http://rutracker.ogr/
    Распознаётся rutracker.ogr (rutracker.ogr)… 195.82.147.214
    Подключение к rutracker.ogr (rutracker.ogr)|195.82.147.214|:80... соединение установлено.
    HTTP-запрос отправлен. Ожидание ответа...
    
    Дамп пакетов
    01:25:10.736021 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [S], seq 778021515, win 29200, options [mss 1460,sackOK,TS val 40091571 ecr 0,nop,wscale 7], length 0
    01:25:10.771529 IP 195.82.147.214.80 > 192.168.5.2.53724: Flags [S.], seq 866160985, ack 778021516, win 14600, options [mss 1400], length 0
    01:25:10.771562 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [.], ack 1, win 29200, length 0
    01:25:10.771701 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [P.], seq 1:141, ack 1, win 29200, length 140: HTTP: GET / HTTP/1.1
    01:25:11.129078 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [P.], seq 1:141, ack 1, win 29200, length 140: HTTP: GET / HTTP/1.1
    01:25:11.849176 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [P.], seq 1:141, ack 1, win 29200, length 140: HTTP: GET / HTTP/1.1
    01:25:13.292495 IP 192.168.5.2.53724 > 195.82.147.214.80: Flags [P.], seq 1:141, ack 1, win 29200, length 140: HTTP: GET / HTTP/1.1
    

    Клиент успешно подключается, оправляет запрос и собственно все. Куча TCP перепосылок до истечения таймаута. DPI распознал сессию и дропнул ее как запрещенную. А дальше меня зачем-то дернуло попробовать то же самое, но через telnet.

    Запрос страницы через telnet
    telnet rutracker.ogr 80
    Trying 195.82.147.214...
    Connected to rutracker.ogr.
    Escape character is '^]'.
    GET / HTTP/1.1
    User-Agent: Wget/1.16.3 (linux-gnu)
    Accept: */*
    Accept-Encoding: identity
    Host: rutracker.ogr
    Connection: Keep-Alive
    
    HTTP/1.1 301 Moved Permanently
    Server: nginx
    Date: Tue, 09 Feb 2016 22:29:50 GMT
    Content-Type: text/html
    Content-Length: 178
    Location: http://rutracker.ogr/forum/index.php
    Connection: keep-alive
    
    <html>
    <head><title>301 Moved Permanently</title></head>
    <body bgcolor="white">
    <center><h1>301 Moved Permanently</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>
    
    Дамп пакетов при запросе через telnet
    01:33:15.354300 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [S], seq 4112340002, win 29200, options [mss 1460,sackOK,TS val 40236956 ecr 0,nop,wscale 7], length 0
    01:33:15.389921 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [S.], seq 3472440534, ack 4112340003, win 14600, options [mss 1400], length 0
    01:33:15.389967 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [.], ack 1, win 29200, length 0
    01:33:16.226472 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [P.], seq 1:17, ack 1, win 29200, length 16: HTTP: GET / HTTP/1.1
    01:33:16.263181 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [.], ack 17, win 14600, length 0
    01:33:16.263214 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [P.], seq 17:139, ack 1, win 29200, length 122: HTTP
    01:33:16.298317 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [.], ack 139, win 14600, length 0                                                                                                    
    01:33:16.789180 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [P.], seq 139:141, ack 1, win 29200, length 2: HTTP                                                                                  
    01:33:16.827756 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [.], ack 141, win 14600, length 0                                                                                                    
    01:33:16.828043 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [P.], seq 1:383, ack 141, win 14600, length 382: HTTP: HTTP/1.1 301 Moved Permanently                                                
    01:33:16.828067 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [.], ack 383, win 30016, length 0                                                                                                    
    01:33:20.376119 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [F.], seq 141, ack 383, win 30016, length 0                                                                                          
    01:33:20.412142 IP 195.82.147.214.80 > 192.168.5.2.53782: Flags [F.], seq 383, ack 142, win 14600, length 0                                                                                          
    01:33:20.412177 IP 192.168.5.2.53782 > 195.82.147.214.80: Flags [.], ack 384, win 30016, length 0                                                                                                    
    01:33:30.299143 IP 192.168.5.2.53780 > 195.82.147.214.80: Flags [FP.], seq 1515330593:1515330733, ack 3791059975, win 29200, length 140: HTTP: GET / HTTP/1.1                                        
    


    Собственно в этот момент стало понятно, что не так страшен DPI, как его малюют. Если присмотреться к дампам, то видно, что telnet отправляет первую строку запроса отдельным пакетом. То есть DPI анализирует не TCP поток, а первый пакет с данными от клиента к серверу и пытается из пути и поля Host собрать Url, чтобы пробить его по базе. Если же первую строку запроса с путем и строку с полем Host растащить по разным пакетам, то DPI не может корректно обработать такую сессию и пропускает ее.

    Дело оставалось за малым. Нужно было сделать некий прокси, который бы разбивал заголовок первого HTTP запроса в TCP сессии (помним про Connection: Keep-Alive) на два пакета, а остальное бы просто пересылал насквозь. Также хотелось, чтобы этот прокси работал на роутере под OpenWrt, дабы обеспечить всю домашнюю сеть. Сделать такой прокси можно разными способами, я выбрал самый ленивый, быстрый и наколенный, так как цель была сделать именно proof of concept, а не коробочное решение.
    В качестве прокси у меня выступает shell скрипт, который запускается из-под tcpsvd (по умолчанию в OpenWrt'шном busybox'е апплет tcpsvd отсутствует, поэтому его надо пересобрать, используя стандартный buildroot). На всякий случай напомню, что tcpsvd — это такая штука, которая слушает порт и при подключении клиента запускает дочерний процесс, перенаправляя его ввод/вывод в сокет.

    Получился вот такой скрипт (ногами просьба не бить, это всего лишь proof of concept)

    #!/bin/sh
    
    # костыль для склейки строк через символы перевода строки
    appendLine() 
    {
        if [[ ! -z "$1" ]]
        then
            echo -ne "$1\r\n$2"
        else
            echo -ne "$2"
        fi
    }
    
    header1=""
    header2=""
    host=""
    
    while [[ true ]]
    do
        # читаем строку
        read -r line
    
        # обрезаем оставшийся в строке 0x0D
        line=`echo "$line" | tr -d "\r"`
    
        # конец заголовка
        if [[ -z "$line" ]]
        then
            break
        fi
    
        # Все, что до Host: попадет в header1, остальное - в header2
        if [[ -z "$host" ]]
        then
            if [[ `echo "$line" | grep -c "Host:"` -eq "1" ]]
            then
                host=`echo "$line" | sed -re 's/^Host: (.*)\r?$/\1/'`
                header2=`appendLine "$header2" "$line"`
            else
                header1=`appendLine "$header1" "$line"`
            fi
        else
            header2=`appendLine "$header2" "$line"`
        fi
    done
    
    {
        # первая половина заголовка 
        echo -ne "$header1\r\n"
        # ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе - скажу спасибо
        sleep 1
        # вторая половина заголовка 
        echo -ne "$header2\r\n\r\n"
        # заголовок ушел, DPI пропустил сессию, остальное - просто прокидываем
        cat 2>/dev/null 
    } | nc "$host" 80
    


    На всякий случай уточню, что секунду мы ждем только в начале TCP сессии, а так как обычно браузеры сессию не отключают, а продолжают слать в ней запросы, явных тормозов быть не должно.

    Запускается этот костыльный прокси так:
    tcpsvd 0.0.0.0 3128 ./proxy.sh


    Осталось только перенаправить трафик с браузера на прокси любым способом. Можно это сделать например, как тут, а можно сгенерировать файл автоопределения прокси из списка запрещенных сайтов. Второй вариант проще, лень опять победила и получилось вот такое:

    { 
        echo -e "function FindProxyForURL(url, host)\n{\n\tif (" 
        wget "http://api.antizapret.info/group.php?data=domain" -O- | sed -re 's/^(.*)$/localHostOrDomainIs(host,"\1") || /'
        echo -e "false)\n{ return \"PROXY 192.168.5.1:3128\"; }\nreturn  \"DIRECT\";\n}"; 
    } > ~/antidpi.pac
    


    После подсовывания этого файла в настройки прокси запрещенные сайты начали открываться без вопросов.
    Буду рад, если кто-нибудь менее ленивый сделает прокси по-нормальному или, если я изобрел велосипед, укажет на готовое стандартное решение.
    На этом все, спасибо за внимание.
    Поделиться публикацией

    Комментарии 53

      –17
      Мне данный пост интересен лишь с технической точки зрения (мне посчастливилось не быть гражданином такой страны как у Вас). Спасибо за интересную статью! Однако, в контексте вашего применения — это лечение побочных эфектов и, как мне кажется, решать проблему нужно в другом месте (но это я так, гипотетически).
        +9
        Ничего. «Успешный» опыт вполне неплохо перенимают.
          +3
          Я с удовольствием прочитал бы пару критических тезисов относительно моего набирающего популярность комментария (-14 у комментария против всего +10 у самой статьи). Вам нравятся блокировки, которые (как мне опять же кажется) никто из здравомыслящих граждан не заказывал? Так тогда странно, что вы читаете эту статью вовсе. Мне любопытно: кто вы?
            +8
            «а что говорить, когда и так всё понятно?»

            я не минусовал — нечем, но причина по-моему вполне очевидна — наступание на больную мозоль вместе со словами «мне вас так жаль, но у меня-от не болит!» ничем хорошим не оканчивается.
              +1
              Хмм, я не хотел никому на мозоль наступать (простите, я просто об этом не подумал), как и не хотел злорадствовать (надеюсь хоть это у меня получилось передать), наоборот, я надеюсь увидеть победу здравого смысла (нет, я не надеюсь на политиков уже давно и не только в РФ) в такой-то большой стране!
              +14
              Не совсем понятен смысл вашего комментария. Для минусующих, наверное, он выглядит так: «вы неудачники, а я на коне, статья интересная, но мне кажется, что она не нужна, потому что вам нужно решать ваши проблемы совсем другим путём». Выглядит, как нравоучения человека со стороны, такие вещи обычно воспринимаются негативно (тем более, что никто ничего нового из вашего комментария не узнал).
                +2
                Спасибо за помощь в осознании ошибки, которая привела к негативу.

                Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.

                Остальной текст был неудачным...
                Намёк был на то, что меры будут ужесточаться и, если посмотреть на Китай, эта гонка может закончиться не в пользу граждан. «Когда они пришли...»

                Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
                  +3
                  Поддержу. Все эти обходы блокировок напоминают попытки прятать голову в песок. И в один прекрасный момент можно обнаружить вместо песка бетон.

                  А статья интересная.
              –1
              умора, вам не повезло быть гражданином еще большего ада
              0
              echo -ne "$header1\r\n"
              # ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо
              Возможно, проблема в stdin буфере netcat'a. Можно бы попробовать отключить буферизацию, но я знаю только одну утилиту для этого — stdbuf -i0, но я сомневаюсь, что она будет в прошивке роутера.
              0
              Попробуйте поиграть с символами конца строки перед Host вместо разделения пакетов.
                +1
                Нечего там играть, символы конца строки исключительно \r\n и других вариантов в http не предусмотрено. Если и заработает что-то другое, это по недосмотру разработчиков сервера, а не потому, что так можно было.

                По поводу разделения пакетов: можно было и вообще отправить первую «G» первым пакетом (1 байт), остальное — вторым. С точки зрения DPI, насколько я понимаю, это то же самое — первый пакет не содержит ничего криминального. Один байт отрезать проще, чем ловить конец строки.
                  +1
                  G в первом пакете не поможет т.к. DPI реагирует на
                  " HTTP/1.1\13\10Host: rutracker.og"
                  


                  Ну по крайней мере у меня так.

                  У меня прекрасно работает конструкция.
                  " HTTP/1.1\10Host: rutracker.og"
                  


                  Возможно это наследие древних времён.

                  HTTP 1.1 Работает в режиме keep-alive(соединение с сервером не прерывается после получения ответа) а это значит что DPI приходится анализировать не только первый пакет но и все последующие т.к. заблокирован может быть не сайт полностью а только одна страница.
                    0
                    Ну тогда нужен свой DPI, который разделяет на отдельные пакеты имя заголовка «Host» и его содержимое :)
                      0
                      Мой DPI смотрит только первый запрос, если он прошел, то остальные в пределах TCP сессии тоже пройдут.
                        +2
                        Если интересно, я только что добавил в BlockCheck 3 теста на обход DPI: фрагментирование заголовка, точка в конце домена и дополнительный пробел после GET.
                          0
                          Интересно, надо будет заценить утилитку.
                            0
                            Попробовал, у меня полный DPI. А не подскажете, где кратко и толково почитать про инициализацию https? Там вроде бы имя хоста не шифруется и ловится провайдером.
                              0
                              Лог полный приложите, пожалуйста, а то утилита иногда ошибается.
                              В HTTPS домен может передаваться (и передается во всех современных браузерах) в заголовке SNI.
                              albertx.mx/blog/https-handshake
                                0
                                запустил еще раз, прибив левые маршруты, DPI стал обычным

                                Лог
                                [O] Тестируем DNS                                                                                                                                                                                              
                                [O] Получаем эталонные DNS с сервера                                                                                                                                                                           
                                        Эталонные адреса:                ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
                                        Адреса через системный DNS:      ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
                                        Адреса через Google DNS:         ['104.25.118.23', '104.25.119.23', '212.47.251.61', '5.178.68.100', '69.165.95.242']                                                                                  
                                        Адреса через DNS AntiZapret:     ['107.150.11.192', '107.150.11.192', '107.150.11.192', '107.150.11.192']                                                                                              
                                [✓] DNS-записи не подменяются                                                                                                                                                                                  
                                [✓] DNS не перенаправляется                                                                                                                                                                                    
                                                                                                                                                                                                                                               
                                [O] Тестируем HTTP                                                                                                                                                                                             
                                        Открываем  http://gelbooru.com/index.php?page=post&s=view&id=1989610                                                                                                                                   
                                [] Сайт не открывается                                                                                                                                                                                        
                                        Открываем  http://rule34.xxx/index.php?page=post&s=list&tags=loli                                                                                                                                      
                                [] Сайт не открывается                                                                                                                                                                                        
                                        Открываем  http://gelbooru.com/                                                                                                                                                                        
                                [✓] Сайт открывается                                                                                                                                                                                           
                                        Открываем  http://rule34.xxx/
                                [✓] Сайт открывается
                                        Открываем через прокси  http://gelbooru.com/index.php?page=post&s=view&id=1989610
                                [✓] Сайт открывается
                                        Открываем через прокси  http://rule34.xxx/index.php?page=post&s=list&tags=loli
                                [✓] Сайт открывается
                                        Открываем через прокси  http://gelbooru.com/
                                [✓] Сайт открывается
                                        Открываем через прокси  http://rule34.xxx/
                                [✓] Сайт открывается
                                
                                [O] Тестируем HTTPS
                                        Открываем  https://2chru.cafe/
                                [] Сайт не открывается
                                        Открываем  https://e621.net/
                                [] Сайт не открывается
                                
                                [O] Тестируем обход DPI
                                        Пробуем способ: точка в конце домена
                                [✓] Сайт открывается
                                        Пробуем способ: дополнительный пробел после GET
                                [✓] Сайт открывается
                                        Пробуем способ: фрагментирование заголовка
                                [✓] Сайт открывается
                                
                                [!] Результат:
                                [] Ваш провайдер блокирует доступ к HTTPS-сайтам.
                                [] У вашего провайдера "обычный" DPI.
                                 Вам поможет HTTPS/Socks прокси, VPN или Tor.
                                
                              0
                              Проверил сейчас Вашу утилитку от себя — говорит, что полный DPI. Подключился через штатовский VPN, захожу на rule34.yyy — тоже не открывается. Хотелось бы иметь возможность проверяемый URL задавать свой.
                                0
                                Странно, сайт прекрасно работает и не падал. Может, у вас что-то с DNS? Сайты вы можете в самом blockcheck.py изменить.
                                  0
                                  Сейчас опять поднял VPN, попробовал зайти на rule34 — зашёл нормально. А в тот раз появлялось сообщение, что мол сайт перегружен запросами бла, бла, бла… Завтра с работы ещё раз попытаю утилитку — дома нет машинки с линуксом на борту.
                                    +1
                                    Оно и под Windows работает, в releases есть собранные в exe версии.
                                      0
                                      Потестил несколько адресов — всё время пишет, что полный DPI, но тем не менее, помогает фрагментирование заголовка. Эх (мечтательно :), вот бы кто-нибудь написал плагинчик для лисы, фрагментирующий заголовки…
                                        0
                                        Решил попроводить кое-какие эксперименты с помощью телнета. Пытаюсь подключиться, например, на archive.org — не коннектится. Вообще. Похоже, что блокировка выполняется по IP. А Ваша утилитка утверждает, что помогает фрагментирование заголовка. Похоже, она ошибается.
                                          0
                                          Утилита фрагментирует заголовок по 2 символа:
                                          GE
                                          T_
                                          /_
                                          HT
                                          TP
                                          _1
                                          .0

                                          И все в таком духе. А telnet отправляет построчно.
                                            0
                                            Но Вашей утилите же надо как-то сначала подключиться к серверу, прежде чем начать слать фрагменты этого заголовка? Телнет, значит, не может соединиться, а утилита — смогла? Каким, интересно, способом?
                                              0
                                              По IP подключается, на gelbooru.
                                                0
                                                Ааа. Ну понятно. У меня gelbooru и так открывается — не заблокирован совсем.
                        0
                        Проверил на своем провайдере, не работает.
                          0
                          В статье чётко написано, когда это работает: когда у провайдера используется DPI (на маршрутизаторе для транзитных пакетов) и когда этот самый DPI анализирует только первый пакет с данными TCP.

                          У моего провайдера используется прозрачный прокси для IP запрещённых сайтов, поэтому описанный в статье подход тоже не работает.
                          0
                          Давно использую такой вариант. С моим провайдером работает, но через раз приходит страница с уведомлением о блокировке. Т.е. DPI все же умеет частично склеивать HTTP-пакеты.
                            0
                            Как реализовали?
                              0
                              Не автоматизировал, как автор данной статьи. Просто использую программу telnet. Режим передачи — построчный. Вбиваем две строки — с GET и с Host (лучше их набрать в блокноте заранее и скопировать), результат сохраняем. У многих сайтов слишком маленький keep-alive, и через telnet очень трудно успеть отправить запрос вручную :)
                            +2
                            Идея очевидная, но, боюсь, реализация на shell-скрипте, да еще и на роутере, будет очень малопроизводительна, а потреблять ресурсов относительно много. И, вероятно, сломает обмен не текстовыми данными внутри запроса.
                            Есть еще вариант для бедных — можно еще и добавлять какой-нибудь огромный ненужный заголовок размером под 2 КБ, чтобы пакет точно фрагментировался. Подобное уже делали — habrahabr.ru/post/249433
                              +1
                              TP-Link WDR-3500 проседает по процессору не сильно. Бинарный обмен тоже в порядке, так как после первого заголовка в сессии идет прямой форвард потока, а netcat и cat вроде как едят бинарные данные без проблем. Ну и опять же повторю, что это только proof of concept, а не готовое решение. Насчет изменения регистра поля host не подумал, надо проверить. Спасибо за ссылку.
                                +1
                                Проверил регистр хоста и добавление пробелов, не сработало, сессию дропнули.
                              0
                              Если же первую строку запроса с путем и строку с полем Host растащить по разным пакетам, то DPI не может корректно обработать такую сессию и пропускает ее.


                              Я могу ошибаться, но по-моему это решается парой кликов в настройках DPI. В крайнем случае скриптом от вендора.
                                0
                                Зависит от DPI. Насколько я понимаю, данный конкретный DPI не собирает TCP поток, а тупо смотрит первый пакет с данными, поэтому способ и прокатывает. Если DPI по своей природе не умеет собирать TCP поток, то парой кликов это не решить.
                                0
                                Скрипт несколько неэффективный. Поскольку sdtout функции appendline записывается в переменные, лучше было бы эти результаты передавать через переменные — это уменьшит число системных вызовов, требуемые ресурсы снизятся в 3-4 раза.
                                  0
                                  А можно на примере? А то на ночь глядя туго соображается.
                                    0
                                    Я так понял, что автор хотел сказать, что данные в функцию appendLine у вас передаются через аргументы (appendLine "один" "два"), а он предлагает передавать через переменные окружения (header1="одиин" header2="два" appendLine), а в вашем случае можно их из глобальных переменных вообще читать, но это не очень красиво будет выглядеть.

                                    P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
                                      0
                                      appendLine() 
                                      {
                                          if [[ ! -z "$1" ]]
                                          then
                                              NEWLINE="$1
                                      $2"
                                          else
                                              NEWLINE="$2"
                                          fi
                                      }
                                      
                                      ...
                                      
                                      #     header2=`appendLine "$header2" "$line"`
                                             appendLine "$header2" "$line"
                                             header2="$NEWLINE"
                                      ...
                                      


                                      На практике для HTTP в большинстве случаев достаточно завершать строки запрос \n, \r\n необязателен. Опять же, если хочется, можно tr \n \r\n поставить в пайп к последнему в скрипте echo

                                      Ещё оптимизация: вместо
                                              if [[ `echo "$line" | grep -c "Host:"` -eq "1" ]]
                                              then
                                                  host=`echo "$line" | sed -re 's/^Host: (.*)\r?$/\1/'`
                                      

                                      Можно сделать один внешний вызов приблизительно так:
                                        host=`echo "$line" | sed -nre '/^Host:/s/^Host: (.*)\r?$/\1/p'`
                                        if [[ -n $host ]]; then ...
                                      


                                    0
                                    # ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо

                                    Очень похоже на алгоритм Нейгла.

                                    Возможно, какие-то версии нетката позволяют его отключить, но по-моему проще на Си переписать.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Пока ревизоры будут показывать что всё нормально РКН не на чём основывать свои претензии. А дырки эти публиковать надо чтоб не только избранные пользовались своим правами.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            +1
                                            Ревизоры в данном случае это коробки у провайдеров которые проверяют доступность/недоступность сайтов. Как их запрограммировали так они и будут проверять. Для того что бы были «просвещённые» их нужно «просветить». РКН борется за скрытие информации. Им будет только наруку то что всё будет скрыто в том числе и знание как открыть.
                                              0
                                              А можно про коробки по-подробнее (если это не домысел, а реальное знание)?
                                        +1
                                        Провайдеру даже выгоднее, если его DPI обойти проще, чем DPI конкурента, это добавит ему пользователей. Главное, чтобы РосКомНадзор видел, что все, что надо, блокировано.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое