В сентябре прошлого года третий по размеру российский мобильный оператор «Вымпелком» и China Telecom подписали соглашение о прямом присоединении сетей международной и междугородной связи и установлении межсетевого взаимодействия, сумма этого контракта составила 2,2 млн. долларов. Целью этой сделки для российской стороны было достижение Дальнего Востока.

За последний год китайский телеком-оператор несколько раз пробовал поиграть в Ивана Сусанина. Об этом подробно пишет Дуг Мэдори в в блоге компании DynResearch.

В переводе с языка обычных людей на язык специалистов заключённая сделка означает, что две компании согласились делиться информацией о динамической маршрутизации по протоколу BGP. И как это часто случается в подобных ситуациях, одна из сторон может выдать данные о маршрутизации от других провайдеров, что поставит её линии связи на пути трафика второй компании. Конкретно с этими двумя компаниями это происходило уже более десятка раз за прошедший год. Это явление случается, но его слабо описывают в литературе по BGP.

Вообще, пиринг BGP — это частое явление в мире крупных сетевых провайдеров, и у этого действия есть несколько смыслов. Конкретно в данном случае под ним понимается маршрутизация таким образом, при которой обмен трафиком происходит свободно, без оплаты его одной из сторон. Без транзитного провайдера можно сильно сэкономить, пусть даже и тратя средства на обслуживания этих пиринговых схем.

В любом случае, информация о маршрутизации, полученная одним из провайдеров от другого по договору о пиринге, обычно остаётся внутри сети этого оператора. В примере ниже провайдер A шлёт информацию о маршрутизации данных его клиентов провайдеру B, в результате чего трафик от клиентов провайдера B идёт через пиринговое соединение клиентам провайдера A. Это нормальный режим работы.



Что-то пойти не так может несколькими различными способами. Провайдер B может взять маршруты от провайдера A и выслать их другим провайдерам, как это показано ниже. Таким образом, провайдер B ставит себя на пути внешнего трафика, предназначенного для провайдера A.



Если провайдер B предоставит маршрут, полученный от провайдеров, к которым он имеет подключение, провайдеру A, то трафик последнего будет идти по этим путям через провайдера B, пусть даже обычно он не должен идти через провайдера B.



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

Итак, за последний год неверная информация о маршрутизации от China Telecom несколько раз попадала в сети «Вымпелкома». Такое произошло, к примеру, 5 августа этого года, когда China Telecom (AS4134) ненадолго предоставила «Вымпелкому» почти всю свою BGP-таблицу (326 622 записи), что привело в резкому росту отклика для пользователей российских провайдеров. Ещё бы — только на путешествие из России в Китай нужно примерно 120 мс. Маршрутизация даже внутри России осуществлялась через сети China Telecom.



Так выглядел результат traceroute: информация начинала свой путь в Вирджинии (США), затем она отправлялась в Калифорнию по сетям NTT, где её передавали China Telecom. Оттуда она шла в Шанхай, а затем в Франкфурт и лишь потом в Россию, в Омск.

Скрытый текст
trace from Reston, VA to Omsk, Russia at 12:00 Aug 05, 2014
1 *
2 129.250.204.153 (NTT America, Ashburn, US) 1.010ms
3 129.250.4.40 (NTT America, Ashburn, US) 0.934ms
4 *
5 129.250.5.13 (NTT America, San Jose, US) 74.649ms
6 129.250.8.6 xe-0.chinanet.snjsca04.us.bb.gin.ntt.net 70.909ms
7 202.97.90.33 (China Telecom, San Jose, US) 71.451ms
8 202.97.58.237 (China Telecom, Shanghai, CN) 341.819ms
9 202.97.58.66 (China Telecom, Frankfurt, DE) 641.424ms
10 118.85.204.58 (China Telecom, Frankfurt, DE) 608.965ms
11 79.104.245.250 pe-r.Omsk.gldn.net 632.054ms
12 195.239.162.178 (Vimpelcom, Omsk, RU) 687.536ms
13 89.179.76.25 vpn2-gi0-0.omsk.corbina.net 682.153ms
14 128.73.155.213 128-73-155-213.broadband.corbina.ru 707.525ms


Для более наглядной иллюстрации ненормальности этой ситуации посмотрим на traceroute «Вымпелкома» до Германии. Трафик идёт от сетей «Вымпелкома» во Франкфурт, затем входит в сети China Telecom, которые доставляют его в Шанхай преж��е, чем отдать Chello Broadband, который имеет договор пиринга с China Telecom в Лос-Анджелесе. Затем Chello Broadband уводит его в Нью-Йорк, оттуда опять в Франкфурт и лишь потом в Германию. За полсекунды трафик как минимум один раз огибает земной шар.

Скрытый текст
trace from Moscow, Russia to Marburg an der Lahn, Germany at 14:29 Aug 05, 2014
1 *
2 194.154.89.125 (Vimpelcom, Moscow, RU) 0.908ms
3 79.104.235.74 mx01.Frankfurt.gldn.net 40.695ms
4 118.85.204.49 beeline-gw2.china-telecom.net 48.799ms
5 202.97.58.61 (China Telecom, Shanghai, CN) 290.810ms
6 202.97.58.202 (China Telecom, Los Angeles, US) 514.115ms
7 202.97.90.62 (China Telecom, Los Angeles, US) 537.933ms
8 213.46.190.217 213-46-190-217.aorta.net (New York) 414.365ms
9 84.116.135.122 (UPC Austria GmbH, Vienna, AT) 420.591ms
10 213.46.160.205 uk-lon02a-rd1-pos-4-0-0.aorta.net 421.530ms
11 84.116.133.65 (UPC Austria GmbH, Frankfurt, DE) 421.557ms
12 81.210.129.234 7111a-mx960-01-ae1.fra.unity-media.net 420.867ms
13 80.69.107.214 7111a-mx960-02-ae0.fra.unity-media.net 418.427ms
14 80.69.107.185 7211a-mx960-01-ae1.gie.unity-media.net 420.454ms
15 88.152.128.0 (Unitymedia, Marburg an der Lahn, DE) 423.105ms


Даже внутрироссийский трафик, который обычно идёт в Москву, шёл через оборудование China Telecom. В следующем примере трафик из Москвы направляется во Франкфурт, затем обрабатывается China Telecom там же и лишь после возвращается в сети «Мегафона». Уж спасибо на том, что не через Шанхай. (Иллюстрация именно этой ситуации на карте Европы показана до ката.)

Скрытый текст
trace from Moscow, Russia to Yaroslavl, Russia at 13:13 Aug 05, 2014
1 *
2 194.154.89.125 (Vimpelcom, Moscow, RU) 0.542ms
3 79.104.235.74 mx01.Frankfurt.gldn.net 37.006ms
4 118.85.204.57 beeline-gw4.china-telecom.net 39.505ms
5 213.248.84.185 ffm-b10-link.telia.net 41.481ms
6 62.115.137.180 ffm-bb2-link.telia.net 42.227ms
7 80.91.251.159 s-bb4-link.telia.net 42.894ms
8 213.155.133.105 s-b2-link.telia.net 41.528ms
9 80.239.128.234 megafon-ic-151430-s-b2.c.telia.net 42.707ms
10 *
11 78.25.73.42 (MegaFon, Volga,RU) 49.992ms
12 213.187.127.98 ysu1-ccr1036-1.yar.ru 50.301ms
13 213.187.117.230 (NETIS Telecom, Yaroslavl’, RU) 54.769ms


Конечно, при планировании сетевого уровня организации Интернета над его безопасностью задумывались слабо, и этих пиринговых утечек вряд ли можно избежать. Но это приводит не только к проблемам с производительностью, но и заставляет сильно беспокоиться о безопасности.

Всё это несколько забавно, если вспомнить, что несколько недель назад официально стало известно о желании российского правительства иметь больший контроль за безопасностью сегмента российского Интернета. Неужели нельзя заняться конкретными вопросами, ведь именно они составляют безопасность нашего сегмента Сети?