Закон парных случаев
Миф о Всесильном Тоталитарном Режиме, стремящимся удушить все Силы Добра, никак не дает покоя представителям этих самых сил. Не успела отгреметь истерика по поводу "цензуры" в ЖЖ, как тут же выпрыгнули очередные умучанные от гэбни.


...
С 1 июня 2007 года значительное число пользователей российского интернета не могут получать информацию с сайтов, входящих в коалицию «Другая Россия» [...] Технической службой указанных сайтов было проведено исследование, в ходе которого удалось установить, что блокирование доступа к сайтам происходит на уровне шлюза у провайдеров

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

Провайдеры прореагировали: "Я - начальник службы передачи данных Зебры Телеком. Нам больше нефиг делать, как заниматься блокировкой сайтов. Увольте дебилов из технической службы."

Ну что ж, проведем собственное, так сказать, исследование. Чем мы хуже этих самых специалистов технической службы, в конце концов?

Из офиса открывается, с машинки на хостнге - нет. Проблема, значится, есть. Проверяем, нет ли по пути каких-нибудь коварных прозрачных прокси, с помощью которых злые спецслужбы мешают нам читать товарща Каспарова:

$ tcptraceroute -w1 -m32 69.36.240.70 80
Selected device eth0, address 89.108.83.67, port 37976 for outgoing packets
Tracing the path to 69.36.240.70 on TCP port 80 (www), 32 hops max
1 c3750-gw.agava.net (89.108.64.1) 23.294 ms 0.431 ms 0.424 ms
2 kiae2-Po-Agava-3.netflow.ru (88.212.194.49) 209.122 ms 120.249 ms 1.630 ms
3 bb-kiae1.2.netflow.ru (88.212.192.65) 0.381 ms 0.450 ms 0.424 ms
4 MSK19-GE11.498.transtelecom.net (217.150.45.194) 0.596 ms 0.502 ms 0.524 ms
5 ge2-8.br01.ams01.pccwbtn.net (63.218.65.21) 50.528 ms 50.559 ms 51.039 ms
6 ge6-12.br02.ash01.pccwbtn.net (63.218.94.50) 138.468 ms 138.799 ms 138.877 ms
7 g6-3-400.core2.eqx.layer42.net (69.36.239.49) 240.642 ms 228.326 ms 228.215 ms
8 te1-1-930.core1.scl.layer42.net (69.36.239.157) 228.796 ms 228.980 ms 228.843 ms
9 po1-vl2.sw2.scl.layer42.net (69.36.225.135) 228.815 ms 229.062 ms 228.801 ms
10 69.36.240.70 [open] 229.094 ms 228.634 ms 228.760 ms
$
$ traceroute -I 69.36.240.70
traceroute to 69.36.240.70 (69.36.240.70), 30 hops max, 38 byte packets
1 c3750-gw.agava.net (89.108.64.1) 0.423 ms 0.452 ms 0.410 ms
2 kiae2-Po-Agava-3.netflow.ru (88.212.194.49) 0.378 ms 0.258 ms 0.244 ms
3 bb-kiae1.2.netflow.ru (88.212.192.65) 0.767 ms 0.415 ms 0.368 ms
4 MSK19-GE11.498.transtelecom.net (217.150.45.194) 0.767 ms 1.205 ms 0.788 ms
5 ge2-8.br01.ams01.pccwbtn.net (63.218.65.21) 50.783 ms 51.057 ms 50.592 ms
6 ge6-12.br02.ash01.pccwbtn.net (63.218.94.50) 138.638 ms 138.561 ms 138.730 ms
7 g6-3-400.core2.eqx.layer42.net (69.36.239.49) 228.384 ms 228.267 ms 228.371 ms
8 te1-1-930.core1.scl.layer42.net (69.36.239.157) 228.796 ms 228.883 ms 228.795 ms
9 po1-vl2.sw2.scl.layer42.net (69.36.225.135) 228.754 ms 309.263 ms 228.633 ms
10 *

Нет, все чисто. Пути трассировки с помощью ICMP и помощью TCP SYN по 80-му порту совпадают. Т.е. TCT-сессию никто никуда не заворачивает, и раньше срока не терминирует.

Попробуем с той же проблемной машинки сходить на тот же сайт, но с другого адреса (у этой машинки два адреса). Чудеса, соединение устанавливается, сайт загружается. Может быть, пакетики с этого адреса идут другим путем?

# tcptraceroute -s 89.108.82.209 -w1 -m32 69.36.240.70 80
Selected device eth0, address 89.108.82.209, port 37979 for outgoing packets
Tracing the path to 69.36.240.70 on TCP port 1111, 32 hops max
1 c3750-gw.agava.net (89.108.64.1) 11.459 ms 0.434 ms 0.413 ms
2 kiae2-Po-Agava-3.netflow.ru (88.212.194.49) 0.362 ms 0.299 ms 0.240 ms
3 bb-kiae1.2.netflow.ru (88.212.192.65) 2.357 ms 2.720 ms 3.206 ms
4 MSK19-GE11.498.transtelecom.net (217.150.45.194) 0.654 ms 0.677 ms 0.542 ms
5 ge2-8.br01.ams01.pccwbtn.net (63.218.65.21) 50.796 ms 50.906 ms 50.683 ms
6 ge6-12.br02.ash01.pccwbtn.net (63.218.94.50) 138.777 ms 138.535 ms 138.601 ms
7 g6-3-400.core2.eqx.layer42.net (69.36.239.49) 228.274 ms 228.628 ms 228.359 ms
8 te1-1-930.core1.scl.layer42.net (69.36.239.157) 228.584 ms 228.740 ms 228.598 ms
9 po1-vl2.sw2.scl.layer42.net (69.36.225.135) 228.935 ms 228.788 ms 228.902 ms
10 69.36.240.70 [open] 228.870 ms 228.570 ms 228.915 ms

Нет, все то же самое.

Уже можно заключить, что проблема не на нашей стороне и не на транзите. Попробуем разобраться детальней.

Человек из Зебры пишет: "Они (69.36.240.70) в SYN-ACKе присылают Windows Size = 0". Это интересно. Берем снифер и смотрим:
19:31:41.969731 IP 89.108.82.209.37743 > 69.36.240.70.80: S 3679692936:3679692936(0)
win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 0>
19:31:42.198587 IP 69.36.240.70.80 > 89.108.82.209.37743: S 3923324648:3923324648(0)
ack 3679692937 win 0 <mss 1380>
19:31:42.198635 IP 89.108.82.209.37743 > 69.36.240.70.80: . ack 1 win 5840

И правда, присылает. Странно. Этого быть не должно. Чешем репу, вспоминаем, что что-то такое уже пролетало как раз в связи с DDoS'ами. Краткий гуглеж и вот оно: Network-based SYN cookie generation". Ух ты, я не знал, что это уже где-то реализовали (_slw@lj подсказывает, что это может быть f5, BIG-IP.

источник-dbg@lj	читать полный текст со всеми комментариями
	читать 4 внешних отзыва