Компания Renesys, которая специализируется на мониторинге интернет-трафика, опубликовала интересное расследование, как внутренний российский трафик перенаправляется по непредсказуемым маршрутам за границу. По мнению аналитиков, это связано с ошибками в конфигурации сетевого оборудования BGP у оператора China Telecom, с которым мобильный провайдер «Вымпелком» в прошлом году подписал соглашение о BGP-пиринге.
За последний год такие ошибки с перенаправлением российского трафика за рубеж происходили более десятка раз, по информации Renesys.
Пиринговые соглашения между операторами связи — вполне нормальное явление. Они позволяют напрямую обмениваться трафиком, экономя на услугах посредников.
Однако, из-за неправильной конфигурации BGP-маршрутизаторов партнёр по пирингу может ошибочно направить чужой трафик в свою сеть. Именно это и происходило в случае с «Вымпелкомом» и China Telecom, как показано на иллюстрации.
Например, один такой случай произошёл 5 августа 2014 года, когда China Telecom (AS4134) передал таблицы маршрутизации трафика «Вымпелкома» (AS3216) своим пирам на несколько часов, в результате чего весь входящий трафик «Вымпелкома» пошёл через маршрутизаторы China Telecom.
Кроме очевидных проблем с безопасностью, такая маршрутизация увеличивает задержку при передаче пакетов. Например, при передаче с американского сервера трафик проходил через узлы China Telecom в Шанхае и Франкфурте.
Более того, даже внутренний российский трафик направлялся через маршрутизаторы China Telecom. Например, пакеты из Москвы в Ярославль путешествовали через Франкфурт.
За последний год такие ошибки с перенаправлением российского трафика за рубеж происходили более десятка раз, по информации Renesys.
Пиринговые соглашения между операторами связи — вполне нормальное явление. Они позволяют напрямую обмениваться трафиком, экономя на услугах посредников.
Однако, из-за неправильной конфигурации BGP-маршрутизаторов партнёр по пирингу может ошибочно направить чужой трафик в свою сеть. Именно это и происходило в случае с «Вымпелкомом» и China Telecom, как показано на иллюстрации.
Например, один такой случай произошёл 5 августа 2014 года, когда China Telecom (AS4134) передал таблицы маршрутизации трафика «Вымпелкома» (AS3216) своим пирам на несколько часов, в результате чего весь входящий трафик «Вымпелкома» пошёл через маршрутизаторы China Telecom.
Кроме очевидных проблем с безопасностью, такая маршрутизация увеличивает задержку при передаче пакетов. Например, при передаче с американского сервера трафик проходил через узлы 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
Более того, даже внутренний российский трафик направлялся через маршрутизаторы 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