В сентябре прошлого года третий по размеру российский мобильный оператор «Вымпелком» и 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
Конечно, при планировании сетевого уровня организации Интернета над его безопасностью задумывались слабо, и этих пиринговых утечек вряд ли можно избежать. Но это приводит не только к проблемам с производительностью, но и заставляет сильно беспокоиться о безопасности.
Всё это несколько забавно, если вспомнить, что несколько недель назад официально стало известно о желании российского правительства иметь больший контроль за безопасностью сегмента российского Интернета. Неужели нельзя заняться конкретными вопросами, ведь именно они составляют безопасность нашего сегмента Сети?
Автор: FakeFactFelis