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

Например, запустив 

   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
   ...