?

Log in

No account? Create an account

Previous Entry | Next Entry

Поставить шлюз между Рунетом и остальной Сетью предлагает президент отечественной ассоциации разработчиков ПО Валентин Макаров. По его мнению, шлюз, через который будет открываться доступ к зарубежным ресурсам, обойдется в несколько сотен миллионов долларов, а его возведение займет около 10 лет. Необходимость защитить Рунет от внешних угроз ранее также высказывал и министр связи Игорь Щеголев.

[...]

Один из самых знаменитых технических ограничителей доступа к глобальным информационным ресурсам реализован в Китае. По сообщению газеты The Epoch Times, «Золотой щит», известный также как «Великий китайский фаерволл» (Great Firewall of China), обошелся стране в $800 млн (6,4 миллиардов юаней). Близкое к Министерству общественной безопасности Китая издание China News Service полагает, что «Великий китайский фаерволл» включает в себя 640 тыс. серверов.


Не буду вдаваться в политические детали этой туфты (про желание присосаться к распилу бабла даже упоминать не буду), но вот про великий китайский фаерволл расскажу отдельно. Дабы сейчас это уже можно.

Всё началось с того, что в Netli (Akamai) решили поставить кластер в Шанхае, ибо многих крупных клиентов (Toyota, etc) заботила скорость передачи данных между сайтами в штатах и их потребителями в континентальном Китае. С превеликим трудом (кластер, посланный через FedEx, оказался сначала в Бразилии, потом его вообще потеряли; деталей и тайминга не помню, помню только суть) кластер был установлен и запущен.

Суть технической реализации Netli-протокола состояла в том, что между кластерами в разных странах протянут специальный протокол (NP/IP, аналог TCP/IP), который имел специальные свойства и реинтерпретированные флаги, делающие его существенно более эффективным чем обычный TCP/IP, но по структуре пакетов L4 он почти полностью совпадал TCP для лёгкого прохода сквозь шлюзы. Запрос, пришедший на кластер в китае, терминировался TCP endpoint'ом прямо там, а дальше шёл через эффективный NP/IP до штатов, где превращался опять в TCP/IP и шёл до конечного сайта.

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

Мы запустили кластер и как-то никаких проблем прохода через фаерволл не обнаружили, и быстро забыли о проблеме — было гораздо больше вещей, над которыми нужно было понервничать. Через эту связку NP/IP мы изнутри китая могли открывать запрещенные сайты, но мы ничего странного в этом факте не видели.

Примерно через месяц-другой Олег Поляков (operations engineer) подошёл и аккуратно, в своём стиле, спросил:
— Лев, я хотел спросить, у нас NP протокол как использует RST флаги? И почему нужно слать по два пакета сразу?

Честно сказать, я охренел.

Поизучав проблему, наше понимание происходящего вдруг расширилось до осознания той диверсии, которую наша компания совершила и продолжала совершать, как говорится, as we spoke. Нас заметил Great Chinese Firewall!

Решили проверить свою догадку: запустили перманентный сниффер, и во дела! Оказалось, что периодически кто-то в поток подмешивает RST пакеты. Теория такая: если фаерволл видит какой-то странный трафик, он тут же его хочет прервать. Прерывает он его посылкой пары TCP пакетов с выставленным RST флагом, сигнализирующим о необходимости экстренно прервать TCP соединение.



Но вот беда, у нас же был не TCP протокол, а NP, очень похожий по структуре пакетов! Плюс, из-за специальных алгоритмов управления потоком, протокол был настолько быстр, что файервол не успевал послать пакеты вовремя! У них были съехавшие sequence numbers, не попадающие в допустимое окно! Очевидно, фаерволл был реализован в виде железки, сидящей рядом с трафиком, а не пропускающим его сквозь себя.

Короче, мы были приятно удивлены тем что происходит — наши железки брут-форсом проломились через великий китайский фаерволл, даже не используя шифрование. И главное — мы не сразу заметили его, а только с течением времени. А если бы у Олега не было привычки сниффер запускать направо и налево? :)

Мы даже успели подумать "а что если у NP вообще отключить реагирование на RST", но решили, что в любой честной охоте нужно дать зверю шанс. Так и работали: раз в несколько дней наш долгоиграющий NP канал всё-таки прерывался, видимо китайский RST успевал вовремя. Но всё быстро восстанавливалось через долю секунды и пёрло дальше без каких-либо препятствий.

Такая вот диверсия.

Tags:

Comments

( 12 comments — Leave a comment )
blacklion
Nov. 8th, 2008 08:06 am (UTC)
А NP и его алгоритмы где-нибудь описаны или великая коммерческая тайна?
Потому как сколько я не изучал протоколы, я плохо вижу место для улучшения основных проблем TCP, за пределом уже сделанного — больших окон, SACK, etc…
lionet
Nov. 8th, 2008 08:18 am (UTC)
Коммерческая тайна, но уже не великая. Сам TCP улучшать очень даже можно, особенно когда чётко известны диапазоны вариации параметров среды передачи (для генерик TCP они, в общем случае, могут быть любыми - от low bandwidth/high delay, до high bandwidth/low delay. Мы оптимизировали для high bandwidth, high delay, поэтому взяли много идей из Vegas (не получившая широкого распространения вариция на тему flow control'а в TCP). Ну и вообще-то NP - это только первый протокол в оптимизированном стеке. Мы ещё оптимизировали HTTP и SSL.

Всё вместе давало нам sub-second performance на загрузке полных страниц (с их содержимым) браузерами где-нибудь в бразилии с серверов где-нибудь в штатах. Эти страницы без Netli открывались за 30-60 секунд.
blacklion
Nov. 8th, 2008 08:22 am (UTC)
Офигеть. Очень интересно было бы про это почитать :) Но, боюсь, даже когда оно станет неактулаьным в коммерческом плане, никто не опубликует :(
blacklion
Nov. 8th, 2008 08:38 am (UTC)
Кстати, Netli очень плохо ищется гуглом ;-) Так что тайна довольно таки великая.
lionet
Nov. 8th, 2008 09:04 am (UTC)
Как это плохо? Мне кучу релевантных ссылок выдало. Просто Akamai удалил брэнд Netli с рынка сразу после покупки.
denlion
Nov. 8th, 2008 08:41 am (UTC)
Гы гы. Когда я трудился в Симкоме и работал на некую фирму PowerSteering в штатах они как раз примерно в середине моей работы стали использовать Akamai. Уж больно мне идея знакомой показалась... я ещё подумал тогда... но как-то не додумался тебя или Влада спросить. Вот ведь совпадения... ;)
lionet
Nov. 8th, 2008 09:06 am (UTC)
Akamai сама по себе технологически сосала. Это, грубо говоря, распределенный кеш. Вот Netli — это уже какой-никакой но protocol intelligence. Если Netli и Akamai присасывались (компетишн!) к какому-то клиенту, то Netli почти неизменно выигрывала, за счёт лучшей оптимизации. Akamai поэтому просто купил Netli и растащил по кусочкам.
mclap
Nov. 10th, 2008 03:01 pm (UTC)
Скажи, NP/IP сделали похожим на TCP/IP чтобы всякие там NAT'ы проходить etc ? ;-)

Т.е. поле Protocol в заголовках IP у него тоже самое (6) ?

p.s. зачОтная оптимизация в 60 раз!
lionet
Nov. 11th, 2008 12:37 am (UTC)
Ага
mclap
Nov. 10th, 2008 03:17 pm (UTC)
Очень интересная история, учитывая где ты работал не так давно и какая компания принимала участие в строительстве GCF. Насколько знаю - это была Cisco ;-)
ad_null
Nov. 11th, 2008 11:48 am (UTC)
Власти не заметили диверсии?
lionet
Nov. 11th, 2008 11:52 am (UTC)
Кто же его знает...
( 12 comments — Leave a comment )

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031
Powered by LiveJournal.com
Designed by yoksel