Сподвиг меня на этот пост вот этот вот комментарий.
Привожу его здесь:
И действительно, kaleman почти угадал с причиной проблем с mail.ru (хотя мы долго отказывались верить в подобное).
Дальнейшее будет разделено на две части:
Ох, это довольно долгая история.
Дело в том, что для реализации требований государства (подробнее во второй части) нами было приобретено, настроено, установлено некоторое оборудование — как для фильтрации запрещённых ресурсов, так и для осуществления NAT-трансляций абонентов.
Некоторое время назад мы наконец перестроили ядро сети таким образом, чтобы весь трафик абонентов проходил через это оборудование строго в нужном направлении.
Несколько дней назад включили на нём фильтрацию запрещёнки (одновременно оставив работать и старую систему) — с виду всё прошло хорошо.
Далее — постепенно стали включать для разных частей абонентов NAT на этом оборудовании. С виду — тоже всё, вроде бы, пошло неплохо.
Но сегодня, включив на оборудовании NAT для очередной части абонентов — с самого утра столкнулись с приличным количеством жалоб о недоступности или частичной доступности mail.ru и других ресурсов Mail Ru Group.
Стали проверять: что-то где-то иногда, изредка шлёт TCP RST в ответ на запросы исключительно к сетям mail.ru. Более того — шлёт неверно сгенерированный (без ACK), явно искусственный TCP RST. Примерно так это выглядело:
Естественно, первые мысли были о новом оборудовании: страшный DPI, доверия к нему никакого, мало ли что он может учудить — ведь TCP RST — это довольно распространённая штука среди средств блокировок.
Предположение kaleman о том, что фильтрует кто-то «вышестоящий», мы тоже выдвинули — но тут же отбросили.
Во-первых, у нас достаточно вменяемые аплинки, чтобы подобным не страдать :)
Во-вторых, мы подключены к нескольким IX в Москве, и трафик до mail.ru идёт именно через них — а уж у них нет ни обязанностей, ни какого-либо другого мотива фильтровать трафик.
Следующая половина дня была потрачена на то, что обычно называют шаманством — вместе с вендором оборудования, за что им спасибо, не бросили :)
Во второй половине дня была выделена виртуалка, выходящая в сеть по схеме обычного пользователя, и к ней и к оборудованию был дан доступ представителям вендора. Шаманство продолжалось :)
В конце концов представитель вендора уверенно заявил, что железка совершенно точно ни при чём: rst`ы приходят откуда-то выше.
После этого, уже вечером — не оставалось ничего другого, как вернуться к предположению о странной фильтрации где-то выше.
Я посмотрел, через какой IX сейчас ходит трафик до сетей МРГ и просто погасил к нему bgp-сессии. И — о чудо! — всё немедленно нормализовалось :(
С одной стороны — очень жаль, что на поиск проблемы был потрачен весь день, хотя решалась она за пять минут.
С другой стороны:
— на моей памяти это беспрецедентная штука. Как я уже писал выше — IX`ам действительно нет никакого смысла фильтровать транзитный трафик. У них его обычно сотни гигабит / терабиты в секунду. Я просто до последнего не мог всерьёз подобного предположить.
— невероятно удачное стечение обстоятельств: новое сложное железо, которому нет особого доверия и от которого непонятно, чего можно ждать — заточенное как раз под блокировку ресурсов, в том числе TCP RST`ами
В настоящий момент NOC этого internet exchange ищет проблему. По их утверждению (и я им верю) никакой специально развёрнутой системы фильтрации у них нет. Но, благодарение небу, дальнейший квест — уже не наша проблема :)
Это была небольшая попытка оправдаться, просим понять и простить :)
P.S.: я намеренно не называю ни производителя DPI/NAT, ни IX (у меня, собственно, даже нет к ним особых претензий, главное — понять, что это было)
Последние недели я провёл, значительно перестраивая ядро сети, производя кучу манипуляций «наживую», с риском значительно затронуть живой пользовательский трафик. Учитывая цели, результаты и последствия всего этого — морально всё это достаточно тяжело. Особенно — в очередной раз слушая прекраснодушные речи о защите стабильности рунета, суверенитете, и т.д. и т.п.
В этом разделе я попытаюсь рассказать «эволюцию» ядра сети типичного интернет-провайдера за последний десяток лет.
Десяток лет назад.
В те благословенные времена ядро провайдерской сети могло быть простым и надёжным, как пробка:
На этой очень-очень упрощённой картинке отсутствуют магистрали, кольца, ip/mpls маршрутизация.
Её суть в том, что трафик пользователей в конечном итоге приходил в коммутацию уровня ядра — откуда шёл в BNG, откуда, как правило — обратно в коммутацию ядра, и далее «на выход» — через один или несколько border gateway's в интернет.
Подобная схема очень-очень легко резервируется как на L3 (динамической маршрутизацией), так и на L2 (MPLS).
Можно поставить N+1 чего угодно: серверов доступа, коммутаторов, бордеров — и так или иначе их зарезервировать для автоматического фэйловера.
Через несколько лет всем в России стало понятно, что так дальше жить нельзя: необходимо срочно защитить детей от тлетворного влияния сети.
Возникла необходимость срочно изыскивать способы фильтровать пользовательский трафик.
Тут есть разные подходы.
В не очень хорошем случае — что-то ставится «в разрез»: между пользовательским трафиком и интернетом. Проходящий через это «что-то» трафик подвергается анализу и, например, в сторону абонента отправляется поддельный пакет с редиректом.
В немного лучшем случае — если обьёмы трафика позволяют — можно сделать небольшой финт ушами: отправлять на фильтрацию только исходящий от пользователей трафик только на те адреса, которые необходимо фильтровать (для этого можно либо брать из реестра указанные там IP-адреса, либо дополнительно резолвить имеющиеся в реестре домены).
В своё время для этих целей я написал простенький мини-dpi — хотя даже язык не поворачивается его так называть. Он очень простой и не очень производительный — однако и нам, и десяткам (если не сотням) других провайдеров он позволил не выкладывать сразу миллионы на промышленные DPI-системы, а дал несколько дополнительных лет времени.
Теперь всё выглядело так:
Ещё через пару лет у всех уже стояли ревизоры; ресурсов в реестре становилось всё больше и больше. Для некоторого старого оборудования (например, cisco 7600) становилась просто неприменимой схема с «фильтрацией сбоку»: число маршрутов на 76 платформах ограничено чем-то около девятиста тысяч, в то время, как число только IPv4-маршрутов сегодня уже подбирается к 800 тысячам. А если ещё и ipv6… А ещё и… сколько там? 900000 отдельных адресов в бане ркн? =)
Кто-то переходил на схему с зеркалированием всего магистрального трафика на фильтрующий сервер, который должен анализировать весь поток и при нахождении чего-то нехорошего слать в обе стороны (отправителю и получателю) RST.
Однако чем больше трафика, тем менее применима подобная схема. При малейшей задержке в обработке — зеркалированный трафик просто незаметно пролетит вникуда, а провайдеру прилетит протокол о штрафе.
Всё больше и больше провайдеров вынуждено ставить DPI-системы разной степени надёжности в разрез магистралей.
Год-два назад по слухам, практически у всех ФСБ стало требовать реальную установку оборудования СОРМ (ранее большая часть провайдеров обходилась согласованием с органами плана СОРМ — планом оперативных мероприятий на случай необходимости что-то где-то найти)
Помимо денег (не так, чтобы прямо уж совсем заоблачных, но всё же — миллионов), СОРМ у многих потребовал очередных манипуляций с сетью.
Поэтому нам, в частности, пришлось здорово перестроить кусок ядра — просто для того, чтобы собрать где-то в одном месте трафик пользователей к серверам доступа. Для того, чтобы несколькими линками отзеркалировать его в СОРМ.
То есть, очень упрощённо, было (слева) vs стало (справа):
Сейчас у большинства провайдеров требуют внедрения также и СОРМ-3 — который включает в себя, в том числе, и логирование нат-трансляций.
В этих целях в схему выше нам пришлось добавить ещё и отдельное оборудование для NAT`а (как раз то, о котором идёт речь в первой части). Причём добавить в определённом порядке: поскольку СОРМ должен «видеть» трафик до транслирования адресов — трафик должен идти строго следующим образом: пользователи -> коммутация, ядро -> серверы доступа -> СОРМ -> НАТ -> коммутация, ядро -> интернет. Для этого нам пришлось, буквально, «разворачивать» потоки трафика в другую сторону наживую, что тоже было довольно непросто.
Итого: за десяток лет схема ядра среднего провайдера усложнилась в разы, а дополнительных точек отказа (как в виде оборудования, так и в виде единых коммутационных линий) — значительно прибавилось. Собственно, само по себе требование «видеть всё» подразумевает сведение этого «всего» в одну точку.
Думается мне, это вполне прозрачно можно экстраполировать на текущие инициативы по суверенизации рунета, его защите, стабилизации и улучшению :)
А впереди ещё Яровая.
Привожу его здесь:
kaleman сегодня в 18:53Дело в том, что, похоже, мы и есть тот самый провайдер :(
Меня сегодня порадовал провайдер. Вместе с обновление системы блокирования сайтов, у него под бан попал почтовик mail.ru. С утра дергаю техподдержку, ничего сделать не могут. Провайдер маленький, и блокируют видимо вышестоящие провайдеры. Еще заметил замедление открытие всех сайтов, может какое-то кривое DLP навесили? Раньше никаких проблем с доступом не было. Уничтожение рунета идет прямо на моих глазах…
И действительно, kaleman почти угадал с причиной проблем с mail.ru (хотя мы долго отказывались верить в подобное).
Дальнейшее будет разделено на две части:
- причины наших сегодняшних проблем с mail.ru и увлекательный квест по их поиску
- существование ISP в сегодняшних реалиях, стабильность суверенного рунета.
Проблемы с доступностью mail.ru
Ох, это довольно долгая история.
Дело в том, что для реализации требований государства (подробнее во второй части) нами было приобретено, настроено, установлено некоторое оборудование — как для фильтрации запрещённых ресурсов, так и для осуществления NAT-трансляций абонентов.
Некоторое время назад мы наконец перестроили ядро сети таким образом, чтобы весь трафик абонентов проходил через это оборудование строго в нужном направлении.
Несколько дней назад включили на нём фильтрацию запрещёнки (одновременно оставив работать и старую систему) — с виду всё прошло хорошо.
Далее — постепенно стали включать для разных частей абонентов NAT на этом оборудовании. С виду — тоже всё, вроде бы, пошло неплохо.
Но сегодня, включив на оборудовании NAT для очередной части абонентов — с самого утра столкнулись с приличным количеством жалоб о недоступности или частичной доступности mail.ru и других ресурсов Mail Ru Group.
Стали проверять: что-то где-то иногда, изредка шлёт TCP RST в ответ на запросы исключительно к сетям mail.ru. Более того — шлёт неверно сгенерированный (без ACK), явно искусственный TCP RST. Примерно так это выглядело:
Естественно, первые мысли были о новом оборудовании: страшный DPI, доверия к нему никакого, мало ли что он может учудить — ведь TCP RST — это довольно распространённая штука среди средств блокировок.
Предположение kaleman о том, что фильтрует кто-то «вышестоящий», мы тоже выдвинули — но тут же отбросили.
Во-первых, у нас достаточно вменяемые аплинки, чтобы подобным не страдать :)
Во-вторых, мы подключены к нескольким IX в Москве, и трафик до mail.ru идёт именно через них — а уж у них нет ни обязанностей, ни какого-либо другого мотива фильтровать трафик.
Следующая половина дня была потрачена на то, что обычно называют шаманством — вместе с вендором оборудования, за что им спасибо, не бросили :)
- полностью отключалась фильтрация
- отключался NAT по новой схеме
- тестовый ПК выносился в отдельный изолированный пул
- менялась IP-адресация
Во второй половине дня была выделена виртуалка, выходящая в сеть по схеме обычного пользователя, и к ней и к оборудованию был дан доступ представителям вендора. Шаманство продолжалось :)
В конце концов представитель вендора уверенно заявил, что железка совершенно точно ни при чём: rst`ы приходят откуда-то выше.
Примечание
В этом месте кто-то может заявить: но ведь гораздо проще было снять дамп не с тестового ПК, а с магистрали выше DPI?
Нет, к сожалению, снять дамп (и даже просто отмиррорить) 40+gbps — совсем не тривиально.
Нет, к сожалению, снять дамп (и даже просто отмиррорить) 40+gbps — совсем не тривиально.
После этого, уже вечером — не оставалось ничего другого, как вернуться к предположению о странной фильтрации где-то выше.
Я посмотрел, через какой IX сейчас ходит трафик до сетей МРГ и просто погасил к нему bgp-сессии. И — о чудо! — всё немедленно нормализовалось :(
С одной стороны — очень жаль, что на поиск проблемы был потрачен весь день, хотя решалась она за пять минут.
С другой стороны:
— на моей памяти это беспрецедентная штука. Как я уже писал выше — IX`ам действительно нет никакого смысла фильтровать транзитный трафик. У них его обычно сотни гигабит / терабиты в секунду. Я просто до последнего не мог всерьёз подобного предположить.
— невероятно удачное стечение обстоятельств: новое сложное железо, которому нет особого доверия и от которого непонятно, чего можно ждать — заточенное как раз под блокировку ресурсов, в том числе TCP RST`ами
В настоящий момент NOC этого internet exchange ищет проблему. По их утверждению (и я им верю) никакой специально развёрнутой системы фильтрации у них нет. Но, благодарение небу, дальнейший квест — уже не наша проблема :)
Это была небольшая попытка оправдаться, просим понять и простить :)
P.S.: я намеренно не называю ни производителя DPI/NAT, ни IX (у меня, собственно, даже нет к ним особых претензий, главное — понять, что это было)
Сегодняшняя (а также вчерашняя и позавчерашняя) реальность с точки зрения интернет-провайдера
Последние недели я провёл, значительно перестраивая ядро сети, производя кучу манипуляций «наживую», с риском значительно затронуть живой пользовательский трафик. Учитывая цели, результаты и последствия всего этого — морально всё это достаточно тяжело. Особенно — в очередной раз слушая прекраснодушные речи о защите стабильности рунета, суверенитете, и т.д. и т.п.
В этом разделе я попытаюсь рассказать «эволюцию» ядра сети типичного интернет-провайдера за последний десяток лет.
Десяток лет назад.
В те благословенные времена ядро провайдерской сети могло быть простым и надёжным, как пробка:
На этой очень-очень упрощённой картинке отсутствуют магистрали, кольца, ip/mpls маршрутизация.
Её суть в том, что трафик пользователей в конечном итоге приходил в коммутацию уровня ядра — откуда шёл в BNG, откуда, как правило — обратно в коммутацию ядра, и далее «на выход» — через один или несколько border gateway's в интернет.
Подобная схема очень-очень легко резервируется как на L3 (динамической маршрутизацией), так и на L2 (MPLS).
Можно поставить N+1 чего угодно: серверов доступа, коммутаторов, бордеров — и так или иначе их зарезервировать для автоматического фэйловера.
Через несколько лет всем в России стало понятно, что так дальше жить нельзя: необходимо срочно защитить детей от тлетворного влияния сети.
Возникла необходимость срочно изыскивать способы фильтровать пользовательский трафик.
Тут есть разные подходы.
В не очень хорошем случае — что-то ставится «в разрез»: между пользовательским трафиком и интернетом. Проходящий через это «что-то» трафик подвергается анализу и, например, в сторону абонента отправляется поддельный пакет с редиректом.
В немного лучшем случае — если обьёмы трафика позволяют — можно сделать небольшой финт ушами: отправлять на фильтрацию только исходящий от пользователей трафик только на те адреса, которые необходимо фильтровать (для этого можно либо брать из реестра указанные там IP-адреса, либо дополнительно резолвить имеющиеся в реестре домены).
В своё время для этих целей я написал простенький мини-dpi — хотя даже язык не поворачивается его так называть. Он очень простой и не очень производительный — однако и нам, и десяткам (если не сотням) других провайдеров он позволил не выкладывать сразу миллионы на промышленные DPI-системы, а дал несколько дополнительных лет времени.
К слову, о тогдашних и нынешних DPI
К слову сказать, многие, кто приобрёл имеющиеся на тот момент на рынке DPI-системы — уже их выкинули. Ну не заточены они под подобное: сотни тысяч адресов, десятки тысяч URL.
И в то же время под этот рынок очень сильно поднялись отечественные производители. Я не говорю про аппаратную составляющую — тут всем всё понятно, однако софт — главное, что есть в DPI — возможно, на сегодня если не самый продвинутый в мире, то уж точно а) развивается семимильными шагами, и б) по цене коробочного — просто несопоставим с зарубежными конкурентами.
Хотелось бы погордиться, но немного грустно =)
И в то же время под этот рынок очень сильно поднялись отечественные производители. Я не говорю про аппаратную составляющую — тут всем всё понятно, однако софт — главное, что есть в DPI — возможно, на сегодня если не самый продвинутый в мире, то уж точно а) развивается семимильными шагами, и б) по цене коробочного — просто несопоставим с зарубежными конкурентами.
Хотелось бы погордиться, но немного грустно =)
Теперь всё выглядело так:
Ещё через пару лет у всех уже стояли ревизоры; ресурсов в реестре становилось всё больше и больше. Для некоторого старого оборудования (например, cisco 7600) становилась просто неприменимой схема с «фильтрацией сбоку»: число маршрутов на 76 платформах ограничено чем-то около девятиста тысяч, в то время, как число только IPv4-маршрутов сегодня уже подбирается к 800 тысячам. А если ещё и ipv6… А ещё и… сколько там? 900000 отдельных адресов в бане ркн? =)
Кто-то переходил на схему с зеркалированием всего магистрального трафика на фильтрующий сервер, который должен анализировать весь поток и при нахождении чего-то нехорошего слать в обе стороны (отправителю и получателю) RST.
Однако чем больше трафика, тем менее применима подобная схема. При малейшей задержке в обработке — зеркалированный трафик просто незаметно пролетит вникуда, а провайдеру прилетит протокол о штрафе.
Всё больше и больше провайдеров вынуждено ставить DPI-системы разной степени надёжности в разрез магистралей.
Год-два назад по слухам, практически у всех ФСБ стало требовать реальную установку оборудования СОРМ (ранее большая часть провайдеров обходилась согласованием с органами плана СОРМ — планом оперативных мероприятий на случай необходимости что-то где-то найти)
Помимо денег (не так, чтобы прямо уж совсем заоблачных, но всё же — миллионов), СОРМ у многих потребовал очередных манипуляций с сетью.
- СОРМу необходимо видеть «серые» адреса пользователей, до nat-транслирования
- У СОРМа ограниченное число сетевых интерфейсов
Поэтому нам, в частности, пришлось здорово перестроить кусок ядра — просто для того, чтобы собрать где-то в одном месте трафик пользователей к серверам доступа. Для того, чтобы несколькими линками отзеркалировать его в СОРМ.
То есть, очень упрощённо, было (слева) vs стало (справа):
Сейчас у большинства провайдеров требуют внедрения также и СОРМ-3 — который включает в себя, в том числе, и логирование нат-трансляций.
В этих целях в схему выше нам пришлось добавить ещё и отдельное оборудование для NAT`а (как раз то, о котором идёт речь в первой части). Причём добавить в определённом порядке: поскольку СОРМ должен «видеть» трафик до транслирования адресов — трафик должен идти строго следующим образом: пользователи -> коммутация, ядро -> серверы доступа -> СОРМ -> НАТ -> коммутация, ядро -> интернет. Для этого нам пришлось, буквально, «разворачивать» потоки трафика в другую сторону наживую, что тоже было довольно непросто.
Итого: за десяток лет схема ядра среднего провайдера усложнилась в разы, а дополнительных точек отказа (как в виде оборудования, так и в виде единых коммутационных линий) — значительно прибавилось. Собственно, само по себе требование «видеть всё» подразумевает сведение этого «всего» в одну точку.
Думается мне, это вполне прозрачно можно экстраполировать на текущие инициативы по суверенизации рунета, его защите, стабилизации и улучшению :)
А впереди ещё Яровая.
