Когда Роскомнадзор блокирует сайты по IP, под блокировку могут попасть и другие, непричастные сайты, которые находятся на том же хосте у провайдера хостинг-услуг. Такое, например, изредка случается с GitHub, если на его же IP-шниках крутится какое-нибудь американское казино.

Для доступа к таким незаконно заблокированным сайтам проще всего использовать VPN. Но если VPN нет, то можно попытаться получить доступ напрямую. Все внешние сайты в России доступны по линиям, контролируемым Ростелекомом, поэтому действия по доступу к заблокированным внешним сайтам для любого внутреннего российского провайдера услуг Интернет будут одинаковыми.

По информации на 2016 год, Ростелеком использует пассивный DPI, т.е. он подключен параллельно, вероятно, пассивным оптическим сплиттером, из-за чего он не может перехватывать отправляемый пакет как таковой, а может только подделать ответ от имени веб-сайта, который перенаправит на страницу-заглушку. Также DPI отправляет перенаправление только с TCP-флагом ACK, хотя обычно используются флаги PSH, ACK. Размер TCP-заголовка тоже всегда равен 20 байтам. Зная эту информацию, для раблокировки сайта у себя на Linux-компьютере, можно написать следующие правила:

# iptables -t raw -A PREROUTING -p tcp --sport 80 -m u32 --u32 "0x1E&0xFFFF=0x5010 && 0x60=0x7761726e && 0x64=0x696e672e && 0x68=0x72742e72" -m comment --comment "Rostelecom HTTP" -j DROP

# iptables -t raw -A PREROUTING -p tcp --sport 443 -m u32 --u32 "4=0x00000000&&0x20=0x50140000" -m comment --comment "Rostelecom HTTPS" -j DROP

Правило iptables для HTTP проверяет TCP-флаги в пакете, пришедшем с 80 порта, его размер, и ищет строку «warning.rt.r» внутри пакета по заданному смещению (строка задается в 16-тиричном виде). Если все совпадает, то отбрасываем этот пакет, и получаем настоящий пакет от сайта.

Для HTTPS, ростелекомовский DPI присылает Reset-пакет (флаги RST, ACK) с нулевым значением TCP-окна и нулями в IP Identification, flags и fragment offset. Такого в реальной жизни не случается, и мы можем отбрасывать все такие пакеты.

Информация взята из обсуждения на Habrahabr: https://habr.com/ru/post/356052/

* * *

Еще один вариант прописывания фильтра iptables приведен ниже и взят с российского сайта OpenNet: https://www.opennet.ru/tips/info/2999.shtml. Здесь больше про обход блокировки, устроенной провайдером или оборудованием внутри корпораций, которое сами админы не могут толком настроить, а работать из такой сети как-то надо.

Провайдеры и корпоративные системы инспектирования трафика применяют для

блокирования доступа к сайтам подстановку пакетов, перенаправляющих браузер

пользователя на страницу с информацией о блокировке, при этом не обрывая

изначально установленное соединение к заблокированному ресурсу.

Например, запустив команду:

tcpdump -nA -s1500 host заблокированный_IP

и попытавшись отрыть заблокированный ресурс в браузере, можно увидеть такой пакет:

13:50:24.563093 IP 1.2.3.4.80 > 192.168.1.10.58072: Flags [.], seq 1777859077:1777859201, ack 3185912442, win 229, length 124

E.......2..a..x$...f.P..i.....*zP....V..HTTP/1.1 302 Found

Connection: close

Location: http://warning.bigprovider.ru/?id=61&st=0&dt=1.2.3.4&rs=http://badsite.com/

следом за которым приходит реальный ответ и другие пакеты с подпадающего под

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

Данный метод блокировки обусловлен тем, что оборудование для обеспечения

блокировки хоть и имеет доступ к транзитному трафику, но оно работает

обособленно от сетевой инфраструктуры и не может изменять трафик или напрямую

блокировать прохождение пакетов. Соответственно, суть применяемого провайдерами

метода состоит в том, что блокирующее оборудование зная параметры сетевого

соединения реализует блокировку через отправку подставного упреждающего ответа.

Так как такой фиктивный ответ приходит раньше реального ответа от удалённого

сервера и снабжён корректным номером последовательности TCP, он воспринимается

клиентским ПО в первую очередь, а пришедший хвост реального ответа игнорируется.

Обойти подобную блокировку достаточно легко при помощи добавления на локальной

Linux-системе правила, отбрасывающего фиктивный ответ:

iptables -I INPUT -p tcp --sport 80 -m string --string "Location: http://warning.bigprovider.ru" --algo bm -j DROP

В случае HTTPS (подобным образом также часто блокируют Tor) блокировка обычно

устраивается через подстановку в трафик RST-пакетов для принудительного обрыва

соединения. Обходится данное ограничение следующим правилом:

iptables -I INPUT -p tcp --sport 443 --tcp-flags RST RST -j DROP

Итог: Даже самые крупные провайдеры лукавят и вместо полноценной блокировки

применяют сомнительные методы подстановки трафика, не блокируя фактически

запрещённый трафик. Таким образом, описанная выше техника не может

рассматриваться как метод обхода блокировки, так как блокировки нет как таковой

- пакеты с запрещённых ресурсов не блокируются и продолжают приходить на

клиентскую систему, а приходящие от провайдера вкрапления лишь создают

видимость блокировки и организуют проброс на стороне клиента.

Клиент имеет полное право отбрасывать любые пакеты на своей системе и это не

может рассматриваться как лазейка для обхода блокировки, которая не выполнена

должным образом провайдером.

Дополнение: Для выявления описанного выше вида блокировок можно использовать

утилиту curl, в которой можно увидеть "хвост" реального ответа:

$ curl -i --ignore-content-length http://badsite.org/

HTTP/1.1 302 Found

Connection: close

Location: http://warning.bitprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=http://badsite.org/

8

Location: http://badsite.org/forum/index.php

Connection: keep-alive

...

Если запросить конечную страницу, то можно получить её содержимое без манипуляций с iptables:

$ curl -i --ignore-content-length --trace-asci dump.txt http://badsite.org/forum/index.php

HTTP/1.1 302 Found

Connection: close

Location: http://warning.bigprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=http://badsite.org/forum/index.php

ection: keep-alive

1fc0

...содержимое HTML-документа.

$ less dump.txt

...

<= Recv header, 20 bytes (0x14)

0000: HTTP/1.1 302 Found

<= Recv header, 19 bytes (0x13)

0000: Connection: close

<= Recv header, 101 bytes (0x65)

0000: Location: http://warning.bigprovider.ru/?id=6&st=0&dt=1.2.3.4&rs=h

0040: ttp://badsite.org/forum/index.php

<= Recv header, 2 bytes (0x2)

0000:

<= Recv data, 1238 bytes (0x4d6)

0000: ection: keep-alive

...