Закон парных случаев
Миф о Всесильном Тоталитарном Режиме, стремящимся удушить все Силы Добра, никак не дает покоя представителям этих самых сил. Не успела отгреметь истерика по поводу "цензуры" в ЖЖ, как тут же выпрыгнули очередные умучанные от гэбни.
С 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
19:31:42.198587 IP 69.36.240.70.80 > 89.108.82.209.37743: S 3923324648:3923324648(0)
ack 3679692937 win 0
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 подсказывает про опенковский synproxy).
Возьмем и поглядим на упешную сессию:
19:32:37.340386 IP 89.108.83.67.37744 > 69.36.240.70.80: S 3732559083:3732559083
(0) win 5840
19:32:37.569260 IP 69.36.240.70.80 > 89.108.83.67.37744: S 3281000991:3281000991
(0) ack 3732559084 win 0
19:32:37.569295 IP 89.108.83.67.37744 > 69.36.240.70.80: . ack 1 win 5840
19:32:37.798403 IP 69.36.240.70.80 > 89.108.83.67.37744: . ack 1 win 5840
Интересна последняя строчка. Та сторона сначала анонсировала нулевое окно, а после завершения 3-way handshake взяла и приоткрыла. Интересно, сам сервер так себя ведет, или перед ним стоит какой-то умный ящик? Поглядим на ту же успешную сессию еще раз:
19:32:37.340386 IP (tos 0x0, ttl 64, id 3058, offset 0, flags [DF], length: 52)
89.108.83.67.37744 > 69.36.240.70.80: S [tcp sum ok] 3732559083:3732559083(0) w
in 5840
19:32:37.569260 IP (tos 0x0, ttl 243, id 34350, offset 0, flags [none], length:
44) 69.36.240.70.80 > 89.108.83.67.37744: S [tcp sum ok] 3281000991:3281000991(0
) ack 3732559084 win 0
19:32:37.569295 IP (tos 0x0, ttl 64, id 3059, offset 0, flags [DF], length: 40)
89.108.83.67.37744 > 69.36.240.70.80: . [tcp sum ok] ack 1 win 5840
19:32:37.798403 IP (tos 0x0, ttl 243, id 39990, offset 0, flags [none], length:
40) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] ack 1 win 5840
19:32:37.798435 IP (tos 0x0, ttl 64, id 3060, offset 0, flags [DF], length: 47)
89.108.83.67.37744 > 69.36.240.70.80: P [tcp sum ok] 1:8(7) ack 1 win 5840
19:32:38.027080 IP (tos 0x0, ttl 52, id 30137, offset 0, flags [DF], length: 40
) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] ack 8 win 5840
19:32:38.042098 IP (tos 0x0, ttl 52, id 30139, offset 0, flags [DF], length: 14
20) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] 1:1381(1380) ack 8 win
5840
Интересное выделено жирным. В ходе сесcий менятся TTL, да еще как меняется. Значит, это какой-то мидлбокс, который проксикует 3-way handshake, а после этого отдает соединение реальному серверу.
Остаются вопросы: что это за мидлбокс, и почему он не всегда отдает сессию серверу? У меня нет на них точного ответа.
Это может быть опенок, хотя я в этом несколько сомневаюсь, может быть какая-то железка, реализующая такую функцию.
Почему оно работает через раз? Можно предположить, что серверов на самомо деле несколько, и между ними делится нагрузка, но лоадбалансинг реализован криво, и часть сессий попадает на нерабочую машине.Может быть, это какое-то переполнение кеша tcp сессий в мидлбоксе (такому мидлбоксу обязательно надо держать состояние сессий, которые бегут через него). Может быть, это какие-то эвристики в этом самом мидлбоксе, и он считатет, что вот с этих блоков DoS'ят, но эта версия маловероятно, в таком случае проще вообще сбрасывать syn'ы из таких блоков.
Ясно одно. Проблема [была?] на стороне хостинга. Спецслужбы опять ни при чем, в "технической службе указанных сайтов" работают люди ... эээ ... как бы это сказать, не совсем компетентные, а в стране дефицит галоперидола.
Upd: dimrub подсказывает, что это может быть f5, BIG-IP.
С 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
19:31:42.198587 IP 69.36.240.70.80 > 89.108.82.209.37743: S 3923324648:3923324648(0)
ack 3679692937 win 0
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 подсказывает про опенковский synproxy).
Возьмем и поглядим на упешную сессию:
19:32:37.340386 IP 89.108.83.67.37744 > 69.36.240.70.80: S 3732559083:3732559083
(0) win 5840
19:32:37.569260 IP 69.36.240.70.80 > 89.108.83.67.37744: S 3281000991:3281000991
(0) ack 3732559084 win 0
19:32:37.569295 IP 89.108.83.67.37744 > 69.36.240.70.80: . ack 1 win 5840
19:32:37.798403 IP 69.36.240.70.80 > 89.108.83.67.37744: . ack 1 win 5840
Интересна последняя строчка. Та сторона сначала анонсировала нулевое окно, а после завершения 3-way handshake взяла и приоткрыла. Интересно, сам сервер так себя ведет, или перед ним стоит какой-то умный ящик? Поглядим на ту же успешную сессию еще раз:
19:32:37.340386 IP (tos 0x0, ttl 64, id 3058, offset 0, flags [DF], length: 52)
89.108.83.67.37744 > 69.36.240.70.80: S [tcp sum ok] 3732559083:3732559083(0) w
in 5840
19:32:37.569260 IP (tos 0x0, ttl 243, id 34350, offset 0, flags [none], length:
44) 69.36.240.70.80 > 89.108.83.67.37744: S [tcp sum ok] 3281000991:3281000991(0
) ack 3732559084 win 0
19:32:37.569295 IP (tos 0x0, ttl 64, id 3059, offset 0, flags [DF], length: 40)
89.108.83.67.37744 > 69.36.240.70.80: . [tcp sum ok] ack 1 win 5840
19:32:37.798403 IP (tos 0x0, ttl 243, id 39990, offset 0, flags [none], length:
40) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] ack 1 win 5840
19:32:37.798435 IP (tos 0x0, ttl 64, id 3060, offset 0, flags [DF], length: 47)
89.108.83.67.37744 > 69.36.240.70.80: P [tcp sum ok] 1:8(7) ack 1 win 5840
19:32:38.027080 IP (tos 0x0, ttl 52, id 30137, offset 0, flags [DF], length: 40
) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] ack 8 win 5840
19:32:38.042098 IP (tos 0x0, ttl 52, id 30139, offset 0, flags [DF], length: 14
20) 69.36.240.70.80 > 89.108.83.67.37744: . [tcp sum ok] 1:1381(1380) ack 8 win
5840
Интересное выделено жирным. В ходе сесcий менятся TTL, да еще как меняется. Значит, это какой-то мидлбокс, который проксикует 3-way handshake, а после этого отдает соединение реальному серверу.
Остаются вопросы: что это за мидлбокс, и почему он не всегда отдает сессию серверу? У меня нет на них точного ответа.
Это может быть опенок, хотя я в этом несколько сомневаюсь, может быть какая-то железка, реализующая такую функцию.
Почему оно работает через раз? Можно предположить, что серверов на самомо деле несколько, и между ними делится нагрузка, но лоадбалансинг реализован криво, и часть сессий попадает на нерабочую машине.Может быть, это какое-то переполнение кеша tcp сессий в мидлбоксе (такому мидлбоксу обязательно надо держать состояние сессий, которые бегут через него). Может быть, это какие-то эвристики в этом самом мидлбоксе, и он считатет, что вот с этих блоков DoS'ят, но эта версия маловероятно, в таком случае проще вообще сбрасывать syn'ы из таких блоков.
Ясно одно. Проблема [была?] на стороне хостинга. Спецслужбы опять ни при чем, в "технической службе указанных сайтов" работают люди ... эээ ... как бы это сказать, не совсем компетентные, а в стране дефицит галоперидола.
Upd: dimrub подсказывает, что это может быть f5, BIG-IP.