Многие провайдеры и корпоративные системы инспектирования трафика применяют для блокирования доступа к сайтам подстановку пакетов, перенаправляющих браузер пользователя на страницу с информацией о блокировке, при этом не обрывая изначально установленное соединение к заблокированному ресурсу.Например, запустив
sudo 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.../
при этом реальный ответ и другие пакеты с подпадающего под блокировку сайта продолжают приходить и не отбрасываются провайдером.
Обойти подобную блокировку достаточно легко при помощи добавления на локальной Linux-системе правила:
sudo iptables -I INPUT -p tcp --sport 80 -m string --string "Location: http://warning.bigprovider.ru" --algo bm -j DROP
В случае HTTPS (подобным образом также часто блокируют Tor) блокировка обычно устраивается через подстановку в трафик RST-пакетов для принудительного обрыва соединения. Обходится данное ограничение следующим правилом:
sudo iptables -I INPUT --sport 443 -p tcp --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:.../
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:...
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
...
URL:
Обсуждается: http://www.opennet.ru/tips/info/2999.shtml
